X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp Subject: Re: Upgrading from a bad C compiler Date: Mon, 13 Aug 2012 03:21:40 -0400 Organization: Aioe.org NNTP Server Lines: 76 Message-ID: References: <17d4b525-2c31-4c20-b3c5-a7118343e9a5 AT googlegroups DOT com><3331145d-900b-4bef-8ad0-f533f0b4a17b AT googlegroups DOT com><83lii3hd5r DOT fsf AT gnu DOT org> <87629514x0 DOT fsf AT uwakimon DOT sk DOT tsukuba DOT ac DOT jp> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org X-Complaints-To: abuse AT aioe DOT org X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.2001 X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Microsoft Outlook Express 6.00.2800.2001 X-Priority: 3 X-MSMail-Priority: Normal Bytes: 4568 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Stephen J. Turnbull" 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