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