http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=42662
User: morriss
Date: 2012/05/16 01:01 PM
Log:
Copy over with manual intervention:
------------------------------------------------------------------------
r42431 | morriss | 2012-05-04 17:56:32 -0400 (Fri, 04 May 2012) | 15 lines
The rest of the fix for https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7221
(emem alignment problems on SPARC) :
Have emem use 8-byte alignment when we need it.
Since I can't seem to write code that which reliably (across GCC versions and
optimization levels) determines if 8-byte alignment is needed for doubles,
"when" is defined as "if we're compiling for a CPU other than i386."
Windows doesn't need a check because it's either i386 or 64-bit (x86_64 or
maybe ia64--both of which get 8-byte alignment from G_MEM_ALIGN).
(And, yes, all of this is ignoring the 16-byte alignment requirements of long
doubles.)
------------------------------------------------------------------------
r42407 | morriss | 2012-05-03 21:33:58 -0400 (Thu, 03 May 2012) | 14 lines
Partial fix for https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7221
(emem alignment problems on SPARC) :
Add the room for the pointer to the next (from r31577) *before* calculating
the canary+pad: that way the complete allocation
(allocation+canary_ptr+canary+pad) will end on an 8-byte boundary (as was the
case before r31577).
This only solves the alignment problem when using canaries (i.e., not, by
default, se_ allocations).
(And, yes, this is ignoring the 16-byte alignment requirements of long
doubles.)
Directory: /trunk-1.4/epan/
Changes Path Action
+2 -2 emem.c Modified
+12 -0 emem.h Modified
Directory: /trunk-1.4/
Changes Path Action
+16 -0 configure.in Modified