Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utcs!mnetor!seismo!columbia!caip!brl-adm!brl-smoke!smoke!gwyn@BRL.ARPA From: gwyn@BRL.ARPA Newsgroups: net.lang.c Subject: Re: Yet another ALIGN idea. (some Message-ID: <2202@brl-smoke.ARPA> Date: Mon, 14-Jul-86 12:07:04 EDT Article-I.D.: brl-smok.2202 Posted: Mon Jul 14 12:07:04 1986 Date-Received: Mon, 14-Jul-86 22:35:34 EDT Sender: news@brl-smoke.ARPA Lines: 31 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 , 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 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 (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.