delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2012/07/31/08:25:46

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
Path: glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.os.msdos.djgpp
Date: Tue, 31 Jul 2012 05:25:37 -0700 (PDT)
In-Reply-To: <83ipd5fbjd.fsf@gnu.org>
Complaints-To: groups-abuse AT google DOT com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=65.13.115.246;
posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO
NNTP-Posting-Host: 65.13.115.246
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>
User-Agent: G2/1.0
X-Google-Web-Client: true
X-Google-IP: 65.13.115.246
MIME-Version: 1.0
Message-ID: <ecaee62c-9827-4eeb-a5b7-493333d7f5f4@googlegroups.com>
Subject: Re: Upgrading from a bad C compiler
From: rugxulo AT gmail DOT com
To: comp DOT os DOT msdos DOT djgpp AT googlegroups DOT com
Cc: djgpp AT delorie DOT com
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q6VCPgM3017704
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Uh, guys, what's the point of this discussion exactly? (I'll guess portability and conformance.)

On Monday, July 30, 2012 11:39:50 AM UTC-5, Eli Zaretskii wrote:
> > From: "Rod Pemberton" <do_not_have AT notemailnot DOT cmm>
> 
> > Date: Mon, 30 Jul 2012 11:51:01 -0400
> 
> > 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.
> 
> > You do realize that C could've added padding even to simple types.  Yes?
> 
> Isn't that what my example with long double demonstrates?

BTW, nitpick (though I'm far far far from expert), you didn't use C99's %z but instead rely on %d to be big enough. But IIRC 2.03p2 didn't support %z.

Vaguely-related question (though haven't seen CWS around lately): I know it's a common idiom to say "return 0" from main, but can't an OS (e.g. VMS ???) have a different value (is it 1 ??). What does their stdlib.h's EXIT_SUCCESS equal? (Yes, I know VMS ain't *nix, but still ....)

> > > Now try the sample program at the end of this message.
> 
> > I ran some other code.
> 
> > OpenWatcom returns 8 ...
> 
> An implementation is allowed to have long double
> be identical to double.  That's what Watcom does,
> evidently.

Probably because 80-bit isn't always supported natively on every cpu. Besides, OW is fairly old, esp. from back when not all computers had FPUs built in (Pentium on up), so perhaps they didn't figure it important enough, esp. if non-standard.

> > DJGPP returns 12.
> 
> > Can I get 10 if I use '#pragma pack(push,1)' ?
> 
> No, you can't.

Did the C11 standard at least standardize on how to pack via attribute or similar?? IIRC, various compilers have different incompatible ways of doing it, which is vaguely annoying. I guess it's not majorly important, but it's frustrating seeing that. (I kinda expect DJ would know, but maybe not.)

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

Okay, but ... that's unavoidable anyways. I think I read somewhere that the FPU context saving (FNSAVE, etc) was always misaligned, hence they suggested the faster FXSAVE (late-model P2s on up). Unfortunately, neither DJGPP (nor our port of GDB) support that, with or without SSE (also unsupported). Not that I really care (or need or understand all of it), mind you, just saying ... things could always be faster (not to mention FISTTP or whatever from SSE3).

But does it matter anyways? Isn't the precision and size of types up to the compiler, runtime, OS, etc. anyways? I mean, x87 works on Win64 "for now", but it'll probably go away eventually. They want everyone to move on up to "faster" SSEx (or maybe eventually AVX ??), which is what latest MSVC 2k10 targets by default now (or so I heard). But SSE2 is limited to 64-bit numbers max, dunno about AVX. I'm sure there's some manual way to do math on bigger types, but I dunno exactly. In short, I'm not sure it's a high priority for them to support 80-bit.

So I have no idea if C11 fixed or allowed for any of that. It's probably a great ideal to try to be portable, but when you have to deal with libraries, OSes, ABIs, and other weird things, sometimes it's useless.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019