align to double or to long double?

[RoSsIaCrIiLoIA]

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)

Can my x86 cpu read an array of long double aligned with double?

union header {
struct { union header* ptr;
unsigned size;
}s;
Align x;
};

typedef union header Header;
static Header base;
static Header *freep=NULL;

 

[Tim Prince]

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.

 

[RoSsIaCrIiLoIA]

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

Thank you
so 8 is ok?

 

[Tim Prince]

Thank you
so 8 is ok?

8-byte alignment is fine for supporting data types T of sizeof(T) <=8, and
there is no advantage in 10- or 12-byte alignment for supporting a 10-byte
long double.