From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9655ac7cb9ecbae44a0a0f3ed3b35361@kw.quanstro.net> References: <1411330.QJAbfBr5F9@blitz> <4FA5E8D2.7090102@gmail.com> <9655ac7cb9ecbae44a0a0f3ed3b35361@kw.quanstro.net> Date: Sun, 6 May 2012 09:57:21 -0400 Message-ID: From: Comeau At9Fans To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=e89a8f642a0e4dcde304bf5e8865 Subject: Re: [9fans] integer width on AMD64 Topicbox-Message-UUID: 85131004-ead7-11e9-9d60-3106f5b1d025 --e89a8f642a0e4dcde304bf5e8865 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 6, 2012 at 9:10 AM, erik quanstrom wrote= : > > Yes, the u{...}int names are important. Those "different names" are > > normally for other (though obviously related) purposes (conceptually > > int_exact_*), and the int_least_* and int_fast_* names, usually are bui= lt > > the int_least_* names appear to me to be completely wasted, given > this is how the normal types are defined and that you couldn't depend > on the extra bits. Kind of. The thing is there is the minimums required by the standard and then there is the minimums provided by the implementation, the latter of which at least has to match the former. But yes, the least names can be viewed to just thrown a wrench into it all. > also, how do you debug code written like this? > Not easily especially when you begin to look at its interaction with I/O as well. > one complete test for each possible definition of int_least_*? > of course, that leads to the question, is that set known? > > one also wonders about int_fast_* as well. fast /for what/ exactly? > IIRC the Standard even specifically leaves that question open. I think the goal was to try to codify/match some existing practice at the time realizing that it wasn't perfect but at least gave a fight chance in some situation and in those it couldn't, there was probably going to be bumps in the road either way. I know it can lead to a why bother situation then. > it seems that all this is in respose to the fact that the c-std version > of u32int is not required. IIRC the full set is not required but I think say uint32_t is. But it's been so long you might just be right. > (the names are somewhat offensive to > good taste, so i refer to them as one does carlin's list, by suggestion.) > rather than fix that issue, layering on another set of types was the > solution. really? > IIRC the naming was raised a number of times. > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm : > > =E2=80=9C It can also be argued that programmers that use the 'intN= _t' more > than > likely really meant to use the 'int_leastN_t' types. Such > programmers > probably want a type with a guaranteed number of bits rather than = an > exact number of bits. > > It can be argued further that use of the 'intN_t' names is not > portable > because they may not exist in all implementations. (An > implementation > is not required to provide these types.) > > unfortunately, there are still programmers who use the definition > more complicated =E2=89=A1 more better. evidently believing in the > transitive nature of "more" over false premises. Personally I could never buy the whole argument for all those names and such, and probably would be happy with just the exact ones. I'm trying to recall the exact etymology of it but it's too long ago to recall. --=20 Greg Comeau / 4.3.10.1 with C++0xisms now in beta! Comeau C/C++ ONLINE =3D=3D> 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? --e89a8f642a0e4dcde304bf5e8865 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, May 6, 2012 at 9:10 AM, erik quanstrom <quanstro@quanstro.net<= /a>> wrote:
> Yes, the u{...}int names are important. =C2=A0Those = "different names" are
> normally for other (though obviously related) purposes (conceptually > int_exact_*), and the int_least_* and int_fast_* names, usually are bu= ilt

the int_least_* names appear to me to be completely wasted, given
this is how the normal types are defined and that you couldn't depend on the extra bits.

Kind of. =C2=A0The thing= is there is the minimums required by the standard and then there is the mi= nimums provided by the implementation, the latter of which at least has to = match the former. =C2=A0 But yes, the least names can be viewed to just thr= own a wrench into it all.
=C2=A0
=C2=A0also, how do you deb= ug code written like this?

Not easily e= specially when you begin to look at its interaction with I/O as well.
=C2=A0
one complete test for each possible definition of int_least_*?
of course, that leads to the question, is that set known?

one also wonders about int_fast_* as well. =C2=A0fast /for what/ exactly?

IIRC the Standard even specifically leav= es that question open. =C2=A0I think the goal was to try to codify/match so= me existing practice at the time realizing that it wasn't perfect but a= t least gave a fight chance in some situation and in those it couldn't,= there was probably going to be bumps in the road either way. =C2=A0I know = it can lead to a why bother situation then.
=C2=A0
it seems that all this is i= n respose to the fact that the c-std version
of u32int is not required.

IIRC the full se= t is not required but I think say uint32_t is. =C2=A0But it's been so l= ong you might just be right.
=C2=A0
=C2=A0(the names are somewhat offensive to
good taste, so i refer to them as one does carlin's list, by suggestion= .)
rather than fix that issue, layering on another set of types was the
solution. =C2=A0really?

IIRC the naming= was raised a number of times.
=C2=A0

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm :<= br>
=E2=80=9C =C2=A0 =C2=A0 =C2=A0 It can also be argued that programmers that = use the 'intN_t' more than
=C2=A0 =C2=A0 =C2=A0 =C2=A0likely really meant to use the 'int_leastN_= t' types. =C2=A0Such programmers
=C2=A0 =C2=A0 =C2=A0 =C2=A0probably want a type with a guaranteed number o= f bits rather than an
=C2=A0 =C2=A0 =C2=A0 =C2=A0exact number of bits.

=C2=A0 =C2=A0 =C2=A0 =C2=A0It can be argued further that use of the 'i= ntN_t' names is not portable
=C2=A0 =C2=A0 =C2=A0 =C2=A0because they may not exist in all implementatio= ns. =C2=A0(An implementation
=C2=A0 =C2=A0 =C2=A0 =C2=A0is not required to provide these types.)

unfortunately, there are still programmers who use the definition
more complicated =E2=89=A1 more better. =C2=A0evidently believing in the transitive nature of "more" over false premises.

Personally I could never buy the whole argument for all tho= se names and such, and probably would be happy with just the exact ones. = =C2=A0I'm trying to recall the exact etymology of it but it's too l= ong ago to recall.

--
Greg Comeau / 4.3.10.1 with C++0xisms now = in beta!
Comeau C/C++ ONLINE =3D=3D> =C2=A0 =C2=A0 http://www.comea= ucomputing.com/tryitout
World Class Compilers: =C2=A0Breathtaking C++, Amazing C99, Fabulous C= 90.
Comeau C/C++ with Dinkumware's Libraries... Have you trie= d it?

--e89a8f642a0e4dcde304bf5e8865--