From owner-freebsd-hackers Wed Jun 12 07:32:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA04918 for hackers-outgoing; Wed, 12 Jun 1996 07:32:56 -0700 (PDT) Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA04906 for ; Wed, 12 Jun 1996 07:32:48 -0700 (PDT) Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id ar13576; 12 Jun 96 15:19 +0100 Received: from jraynard.demon.co.uk ([158.152.42.77]) by relay-3.mail.demon.net id aa17510; 12 Jun 96 14:56 +0100 Received: (from fhackers@localhost) by jraynard.demon.co.uk (8.7.5/8.6.12) id LAA05014; Wed, 12 Jun 1996 11:09:09 GMT Date: Wed, 12 Jun 1996 11:09:09 GMT Message-Id: <199606121109.LAA05014@jraynard.demon.co.uk> From: James Raynard To: bde@zeta.org.au CC: freebsd-hackers@freebsd.org In-reply-to: <199606120041.KAA21730@godzilla.zeta.org.au> (message from Bruce Evans on Wed, 12 Jun 1996 10:41:59 +1000) Subject: Re: Header files Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> Bruce Evans writes: > > >2. The stdio library requires fpos_t to be an 8-byte type. In stdio.h, > > it's typedef'd as an off_t if neither _ANSI_SOURCE or > > __STRICT_ANSI__ are defined, with a comment saying "When we switch > > to gcc 2.4 we will use __attribute__ here." > > > Do we have any plans to switch to gcc 2.4? 8-) > > I plan to fix this when we switch to gcc-2.7. The necessary attribute is > > __attribute__((__mode__(__DI__)) > > but __DI__ isn't supported in versions of gcc before 2.7. gcc-2.4 through > gcc-2.6 support > > __attribute__((__mode__(DI)) > > but this can't be used since an application might define DI. I see. Thanks. > I actually plan to declare fpos_t as __BSD_OFF_T__ and define __BSD_OFF__ > using __attribute__. I've got some patches (which I'll commit tonight) that get stdio to compile cleanly with gcc -Wall. I tried throwing in a few more warnings, including -ansi, just for fun, and got tons of complaints about fpos_t, which is why I started looking at it. (Although -ansi isn't really appropriate for this kind of code anyway). > >3. has a comment saying that 2147483648 is an > > unsigned int for 32-bit two's complement ANSI compilers. However, > > it's an unsigned long for 32-bit ANSI compilers, regardless of the > > binary encoding used. > > Ugh. The corresponding problem doesn't occur for UINT_MAX because > UINT_MAX is defined as a hex literal and the type rules work more > naturally for hex. However, our ULONG_MAX is broken in the opposite way > (it has type `unsigned'). It should be be written as 0xffffffffUL, as you mention below. > The comment could be fixed by writing 0x80000000. I prefer to write all > the limits in hex anyway. I did this for 386BSD-0.1 and FreeBSD-1.x > inherited the changes, but 4.4BSDLite did it differently. NetBSD writes > all the limits in hex and uses `U' and `L' suffixes to get the types > right. It also uses a `U' suffix for UCHAR_MAX and USHRT_MAX to get the > types wrong (`unsigned', but should be `int' for the i386, since the > integral promotions convert both unsigned char and unsigned short to int. > There are longstanding bugs and bogons in our definitions of the quad > limits. A comment says that gcc requires that they be written as > expressions. This isn't true for gcc-2.6. gcc in fact screws up the > expressions. E.g., this breaks strtouq(). strtouq("4294967296", 0, 0) > returns 18446744073709551615ull instead of 4294967296ull > (18446744073709551615 may be more recognisable if it is written as > 0xffffffffffffffff or 2^64 - 1). This is fixed in gcc-2.7. Oh, I didn't realise that. -- James Raynard, Edinburgh, Scotland james@jraynard.demon.co.uk jraynard@FreeBSD.ORG