Yet another ALIGN idea. (some

gwyn at BRL.ARPA gwyn at BRL.ARPA
Tue Jul 15 02:07:04 AEST 1986


Who says stack alignment has to be the same as machine-forced
alignment?  It's certainly not on some of the machines I use.

Since the parameter stack can have different alignment constraints,
one would actually need a stkalignof operator for <stdarg.h>, but
it would be of use only for this one purpose and therefore should
not be intruded upon the programmer's notice.

It's true that it would be easier to implement <stdarg.h> on some
machines if the alignof operator were available, but it's not
required.  Indeed, since the compiler can tell that variable-
parameter functions are involved, it may choose to use what we
old-timers call "dope vectors" to describe the variable args.

On some unusual architectures, actual library functions may have
to be used in the implementation of va_arg() (which itself is a
macro).

There was a motion last meeting to drop parmN, but it was defeated;
however, we decided to make "register" parmN an undefined situation.

Although I can't recall anything that requires all structs to
be aligned as stringently as the worst possible scalar data type,
implementations may elect to do so, or to make special arrangements
so that the size and alignment of very small structs are convenient
for <stdarg.h> (besides having to include padding so that arrays of
structs work out right).

The reference in the draft standard to int, unsigned int, and
double was with respect to possible result of parameter widening
promotions; it wasn't meant to rule out other parameter types.



More information about the Comp.lang.c mailing list