From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <1411330.QJAbfBr5F9@blitz> References: <1411330.QJAbfBr5F9@blitz> Date: Sat, 5 May 2012 17:00:24 -0400 Message-ID: From: Comeau At9Fans To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=14dae93998336f477504bf505384 Subject: Re: [9fans] integer width on AMD64 (was: Re: AMD64 system) Topicbox-Message-UUID: 84281b08-ead7-11e9-9d60-3106f5b1d025 --14dae93998336f477504bf505384 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 5, 2012 at 11:33 AM, dexen deVries wrote: > On Wednesday 25 of April 2012 15:32:06 erik quanstrom wrote: > > also, in case you missed it sizeof(int)==sizeof(long)==4 on both 32 > > and 64 bit plan 9, so recompiled programs won't get bigger integers > > just for the recompiling. > > > pardon silly question, but... why, on 64bit machine, P9 uses 32bit ints and > longs? > > my impression is, int was supposed to match machine's preferred (best > performance etc.) integeral datatype, and long was supposed to be enough to > hold a pointer? (i.e., sizeof(long) >= sizeof(void*)) Re "supposed" if you mean according to say Standard C, no. Even so-called K&R C was not black and white regarding this per se. Standard C only provided minimum sizes. Indeed, there is often preferences, but that's usually up to vendors, and lots of it yield *-defined behaviors. As it should. There is also the issue of that, if, you really want a 64-bit integer, then, using int is certainly moving towards a direction of a programming error, since int does not often yield such a beast, even on so-called systems which could provide it. C99 provides for stuff such as int_least64_t for those who really need such. -- Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries... Have you tried it? --14dae93998336f477504bf505384 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, May 5, 2012 at 11:33 AM, dexen deVries <dexen.devries@gmail.= com> wrote:
On Wednesday 25 of April 2012 15:32:06 erik quanstrom wrote:
> also, in case you missed it sizeof(int)=3D=3Dsizeof(long)=3D=3D4 on bo= th 32
> and 64 bit plan 9, so recompiled programs won't get bigger integer= s
> just for the recompiling.


pardon silly question, but... why, on 64bit machine, P9 uses 32bit ints and=
longs?

my impression is, int was supposed to match machine's preferred (best performance etc.) integeral datatype, and long was supposed to be enough to=
hold a pointer? (i.e., sizeof(long) >=3D sizeof(void*))


Re "supposed" if you mean accordin= g to say Standard C, no. =A0Even so-called K&R C was not black and whit= e regarding this per se. =A0Standard C only provided minimum sizes. =A0Inde= ed, there is often preferences, but that's usually up to vendors, and l= ots of it yield *-defined behaviors. =A0As it should.

There is also the issue of that, if, you really want a = 64-bit integer, then, using int is certainly moving towards a direction of = a programming error, since int does not often yield such a beast, even on s= o-called systems which could provide it. =A0C99 provides for stuff such as= =A0int_least64_t for those who really need such.

--
Greg Comeau / 4.3.10.1 with C++0xisms now = in beta!
Comeau C/C++ ONLINE =3D=3D> =A0 =A0 http://www.comeaucompu= ting.com/tryitout
World Class Compilers: =A0Breathtaking C++, Amazing C99, Fabulous C90.=
Comeau C/C++ with Dinkumware's Libraries... Have you tried i= t?

--14dae93998336f477504bf505384--