X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
From: "Stephen J. Turnbull" <turnbull AT sk DOT tsukuba DOT ac DOT jp>
To: djgpp AT delorie DOT com
Subject: Re: Upgrading from a bad C compiler
In-Reply-To: <jv6ad7$vqc$1@speranza.aioe.org>
References: <17d4b525-2c31-4c20-b3c5-a7118343e9a5 AT googlegroups DOT com>
	<jucp01$p35$1 AT speranza DOT aioe DOT org>
	<b1f8c389-45f4-43e4-9056-62fc50fc9462 AT googlegroups DOT com>
	<juh7c1$7hk$1 AT speranza DOT aioe DOT org>
	<3331145d-900b-4bef-8ad0-f533f0b4a17b AT googlegroups DOT com>
	<juuseq$j7b$1 AT speranza DOT aioe DOT org>
	<a7htthFse5U1 AT mid DOT dfncis DOT de>
	<jv1ect$iv$1 AT speranza DOT aioe DOT org>
	<83lii3hd5r DOT fsf AT gnu DOT org>
	<jv6ad7$vqc$1 AT speranza DOT aioe DOT org>
X-Mailer: VM 8.0.12-devo-585 under 21.5  (beta31) "ginger" b4715fcbe001
 XEmacs Lucid (x86_64-unknown-linux)
Date: Tue, 31 Jul 2012 03:26:35 +0900
Message-ID: <87629514x0.fsf@uwakimon.sk.tsukuba.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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.

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

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