🚀 go-pugleaf

In article <j66Sx*FRe@yaps.rhein.de>,
Arno Eigenwillig <arno@yaps.rhein.de> wrote:
>
>That is a quality-of-implementation issue and hence beyond the scope
>of The Standard. All The Standard defines in the end is the output a C
>program creates, not the timing nor (thanks to the as-if rule) the way
>it creates it.
>
My question is what the committee means by the words "proper alignment". If
"proper" COMPLETELY ignores efficiency consideration even if they are
gross, it means that I would have to align all malloc() returns according to
the size of the data in all portable code I write. However, I've never seen
an "ANSI C" textbook that advises aligning malloc() returns by hand. So
the interpretation that completely ignores reasonable efficiency expectations
is incompatible with the way people are taught to code portably in C.

For this reason, the two possibilities are:

1) All the texts (including K & R) are advocating code that is not reasonable
on (the most common) compliant implementations of C.

or

2) 32 bit alignment of malloc() on PCs is not compliant.

Either possibility is very serious, and violates assumptions that most 
programmers take for granted


Regards,

Mike