delorie.com/archives/browse.cgi | search |
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 |
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 |
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".
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |