X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "Rod Pemberton" <do_not_have AT notemailnot DOT cmm>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Upgrading from a bad C compiler
Date: Mon, 13 Aug 2012 03:17:55 -0400
Organization: Aioe.org NNTP Server
Lines: 95
Message-ID: <k0a9im$fro$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> <83ipd5fbjd DOT fsf AT gnu DOT org>
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: 4173
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

"Eli Zaretskii" <eliz AT gnu DOT org> wrote in message
news:83ipd5fbjd DOT fsf AT gnu DOT org...
> > From: "Rod Pemberton" <do_not_have AT notemailnot DOT cmm>
> > Date: Mon, 30 Jul 2012 11:51:01 -0400
> >
...

> > No, I've made no claims about what sizeof() should or shouldn't return.
>
> You said it "works" (i.e. the results are evident in advance) for
> primitive data types.  My point was that even that is not true.
>

I understood your point.  It was wrong.  Still is.  Unless, that is, you're
able to prove otherwise, which you haven't been able to do or done so, so
far.

> > Although, I do have a preference.  I was talking about possible
> > expectations by others.  I.e., what does 'sizeof()' mean to someone
> > using it?  What do they expect to get from it?  What 'size of' is
> > expected to be returned?
>
> It is expected to return the size that its argument takes in storage.
>

Just how do you define that?  I presented two possible valid interpretations
of that previously as "expectations".  I also presented what the C
specification says in "Sub 3 of 6.5.3.4 of ISO C99" in response to you.
Now, I'm not nitpicking, but you are definately avoiding the question.

> > You do realize that C could've added padding even to simple types.  Yes?
>
> Isn't that what my example with long double demonstrates?
>

No.  Unfortunately, you used circular logic.  You took an implementation,
which may or may not be correct in it's implementation, assumed that it is
correct, and concluded that your premise leading to the conclusion must also
be true.

http://en.wikipedia.org/wiki/Circular_reasoning


> > > Now try the sample program at the end of this message.
> >
> > I ran some other code.
> >
> > OpenWatcom returns 8 ...
> >
> > OpenWatcom
> > long double 8
> > double 8
> > float 4
>
> An implementation is allowed to have long double be identical to
> double.  That's what Watcom does, evidently.
>
> > DJGPP returns 12.
> >
> > DJGPP
> > long double 12
> > double 8
> > float 4
> >
> > Can I get 10 if I use '#pragma pack(push,1)' ?
>
> No, you can't.
>
> > If DJGPP is storing a mem80 for a 'long double' and 10 can never be
> > returned by sizeof(), then DJGPP's sizeof() is broken.
>
> No, it isn't.  It's your interpretation of sizeof that's broken.
>

Really?  Explain how so in the context of the specification.  I wasn't
familiar with sizeof(), yet I explained it within the context of the
specification.  Can't you do so?  Please cite the sections and your
reasoning,  If you can't, which seems to be the case here, it strongly
implies _your_ understanding is incorrect.

> > Or, if the two extra bytes are to store something relevant for a 'long
> > double', say x87's control word
>
> No, they are for the proper alignment of array elements in an array of
> long double.  Accessing an element that is not aligned on a 4-byte
> boundary means severe runtime penalty.

So?

That would be broken as stated previously.


Rod Pemberton