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

[wdoekes]

-----------------------------------------------------------
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.


Changes
-------

(a) Moved the "ugly" alignment calculations to a define in include/asterisk/utils.h.

(b) Added a second define because I was losing two bytes in the "grow" case.

(c) Replaced the calloc of pool_struct+data in add_string_pool() to a malloc and a memset. Setting the whole allocated space to 0 is nonsense; only pool needs to be nulled.
The only calls to add_string_pool() are here:
- __ast_string_field_init() [the fields are initialized to __ast_string_field_empty in the start of the function]
- __ast_string_field_alloc_space() [data is initialized in __ast_string_field_ptr_build_va and ast_string_field_ptr_set]
So this change should be safe.


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 (updated)
-----

  /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/20111031/6f56c830/attachment.htm>