[asterisk-dev] [Code Review]: ensure that ast_string_field_pool base + used is always aligned

[wdoekes]

> On Oct. 31, 2011, 12:34 p.m., mjordan wrote:
> > /branches/1.8/main/utils.c, line 1548
> > <https://reviewboard.asterisk.org/r/1549/diff/2/?file=21505#file21505line1548>
> >
> >     This actually goes against the recommendations in the coding guidelines (2.17.3) - is there a specific reason to not use ast_calloc?
> 
> David Vossel wrote:
>     The memset after the malloc is for a smaller amount of memory than the entire allocation.  The change appears safe, but I question why we'd even care about this optimization when it adds more complexity.

This isn't an increase in complexity, this is a fix. The original author should never have used calloc here. This is a very common pattern.

I don't see how you could not care about the overhead of hundreds of bytes getting nulled for nothing when only a handful (struct ast_string_field_pool) should get nulled. Especially in core functions that were created to reduce load (individual string field mallocs) in the first place.


- wdoekes


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1549/#review4615
-----------------------------------------------------------


On Oct. 31, 2011, 3:47 a.m., wdoekes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1549/
> -----------------------------------------------------------
> 
> (Updated Oct. 31, 2011, 3:47 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch fixes that Asterisk can be properly built on certain architectures that dislike misalignment. (In the case of the bug reporter, an ARM.)
> 
> ==Background==
> Currently the 16bit ast_string_field_allocation used in the is not aligned, it can be stored on an 8bit boundary. Certain machines will either SIGBUS over this or simply give wrong results. For the Sparc an #ifdef was added to alleviate the problem.
> 
> ==Problems with current approach==
> (1) The x86 can cope with misaligned integers, but for performance, aligned ints are better.
> (2) The #ifdef did not catch all architectures that dislike misalignment.
> (3) The code in the #ifdef falsely assumes that the ast_string_field_allocation is at most 2 bytes large. If this were to change one day, things would start to fail again.
> 
> ==Possible fixes==
> (1) Remove the #ifdef, always run the Sparc code and patch it to cope with larger than 16bit ast_string_field_allocation's.
> (2) Alter all ast_string_field_allocation code to ensure that base and used stay aligned. Then we won't need to check and re-align later on.
> 
> I chose fix #2 because I believe this to be marginally faster and more logical. This does involve the use of the gcc __attribute__((aligned)). But the other code is full of gcc attributes, so I don't think I'm breaking a build anywhere with this.
> 
> Regards,
> Walter
> 
> 
> This addresses bug ASTERISK-17310.
>     https://issues.asterisk.org/jira/browse/ASTERISK-17310
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/include/asterisk/utils.h 342659 
>   /branches/1.8/main/utils.c 342659 
>   /branches/1.8/include/asterisk/stringfields.h 342659 
> 
> Diff: https://reviewboard.asterisk.org/r/1549/diff
> 
> 
> Testing
> -------
> 
> I replaced:
> typedef uint16_t ast_string_field_allocation;
> with:
> typedef uint64_t ast_string_field_allocation;
> 
> Then I looked at a small sample of base and used during operation.
> 
> They were always 64bit aligned.
> 
> 
> Thanks,
> 
> wdoekes
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111101/6dd93912/attachment.htm>