"RoSsIaCrIiLoIA" <n@esiste.ee> wrote in message
news:r3********************************@4ax.com...
I have rewrote the malloc() function of K&R2 chapter 8.7
typedef long Align;
^^^^
Here, should I write 'long', 'double' or 'long double'?
I know that in my pc+compiler sizeof(long)=4, sizeof(double)=8
and sizeof(long double)=10
(if 'long' or 'double' sizeof(Header)=8 if 'long double'
sizeof(Header)=12)
Taking up 12 bytes for a 10-byte type helps only in that it sets up padding
for a following 4-byte type. It doesn't align a following 8-byte or larger
type properly.
Can my x86 cpu read an array of long double aligned with double?
Yes, the hardware fixes up such mis-alignments, and the performance
consequences aren't a Standard C issue. One might argue that malloc()
should return a pointer which will allow 128-bit data types to work, at the
same time giving full performance for long double. Practice hasn't evolved
that way, requiring instead that malloc() be discarded in favor of
implementation-dependent replacements. The argument is more often made that
malloc() shouldn't even have 8-byte alignment, given that the hardware has
some support for fixing up alignments. Standard C says something about
"suitability" of alignment. There seems room for more than one view of what
that means, but anyway there is little advantage to offering alignments
other than 8- or (some implementations 4-) or 16- bytes.