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

[Terry Wilson]

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

Ship it!


This looks good to me. I've tested the patch with the stringfields unit test while running under valgrind and it passes. I don't have a platform where it really matters to test on, but the macros look right and produce the right values when I plug in various numbers.

- Terry


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/20111102/6215f63d/attachment.htm>