Mail Archives: djgpp/2012/08/13/03:30:13.1
"Stephen J. Turnbull" <turnbull AT sk DOT tsukuba DOT ac DOT jp> wrote in message
news:87629514x0 DOT fsf AT uwakimon DOT sk DOT tsukuba DOT ac DOT jp...
> Rod Pemberton writes:
>
> > I also stated that sizeof() actually does return different things
> > in different contexts. It does. It works differently depending on
> > the data type. For some data types, it doesn't add padding. You
> > probably think of them as not having padding, but it's there for
> > them too.
>
> sizeof doesn't "add" padding for *any* type. sizeof itself doesn't
> need to do addition at all, most likely; almost certainly size is an
> entry in the symbol table. It is the allocation code that adds
> padding. sizeof merely reports the size of the object.
>
... which, if padded, like a union or struct, returns padding ...
You're playing word games.
> > If DJGPP is storing a mem80 for a 'long double' and 10 can never be
> > returned by sizeof(), then DJGPP's sizeof() is broken. AISI, the
> > specification agrees with me.
>
> No, it doesn't. The storage layout of the bits of an atomic type is
> entirely up to the compiler. That's what "atomic" means. I forget
> what machine it was (maybe the Cray XMP?), but there was a CPU where
> it made sense for chars to be stored one per 64-bit word. If DJGPP
> uses the FST instruction to move a long double from an FPU register to
> memory, it doesn't mean that it stores an mem80 in 12 bytes; it means
> that DJGPP's memory format for long double is not mem80, that's all.
>
See "Sub 3 of 6.5.3.4 of ISO C99".
> > Sub 3 of 6.5.3.4 of ISO C99 only allows for padding of unions and
> > structs. Excluding padding for union and structs, there is no
> > provision in ISO C99's 6.5.3.4 section for sizeof() to return storage
> > space *beyond* what is required for storage of a C type or expression.
>
> What you're missing is that the *compiler implementer* decides what is
> "required for storage".
If the *compiler implementor* "decides what is 'required for storage'"
instead of using only what's needed and only padding structs or unions, then
_clearly_ it's non-compliant. Yes? That's what Sub 3 of 6.5.3.4 of ISO C99
says. Doesn't it? If not, please explain in context of the specification.
Where does 6.5.3.4 of ISO C99 allow other values to be returned for
sizeof()?
If there is no point in complying with Sub 3 of 6.5.3.4 of ISO C99 for
sizeof(), then there is no point in complying with anything else in the
specification. Yes? So, what's the purpose of the specification in the
first place?
This is one of the problems with specifications not specifying low-level
implementation details. You can't build a house without a foundation.
Every time a difference in interpretation of a specification arises, someone
must fall back upon the details of a specific implementation, usually an
ancient and obsolete implementation. I.e., Eli using mem80 for DJGPP or you
using possibly a Cray XMP for 64-bit chars (early Cray's were word aligned),
or the c.l.c. favorite of 9-bit chars on some unknown machine, or 7-bit or
9-bit chars on 36-bit word size PDP-10, or 16-bit word size on PDP-11, etc.
S.P. Harbison and G.L. Steele, S.C. Johnson and D.M. Ritchie, and others,
e.g., D.A. Gwyn, have all written about how C fits a byte addressable
machine well, but has problems on other architectures.
Rod Pemberton
- Raw text -