Sizes of Integer Types

[Flash Gordon]

Kelsey Bjarnason wrote, On 13/09/07 20:28:

[snips]

If writing a typedef will do the job, then so will the new int type.

Making the new int type at best a convenience.

The difference is that the new int type will work on *all*
implementations which have *any* suitable type

Rather than "on all implementations", where, oh, int and char will
continue to work.

No it won't, unless just because you compile this application the size
of char suddenly changes. It will compile, yes, but that is not the same
as working.

Again, exactly my point. What _could have been_ a wonderfully useful
notion has instead become little more than a way to limit the portability
of the code.

Portability is not binary. Do you think POSIX specific code is
completely non-portable because it won't run on non-posix systems? If so
you have completely failed to understand what portability means. Fixed
size integer types are exactly the same, as are objects above the
minimum size guaranteed by the standard.

If all code has to be portable to all systems tell me how to port code
for manipulating live video with 1MB per frame on a processor with only
8K of RAM and no communication mechanism fast enough to get 1MB on to it
during one frame.

 

[Ed Jensen]

Hmm. I win. My code's running, yours needs porting.

No, you lost.

Someone else did it in 1/4 the time, because they used a sane language
with fixed size primitives in the first place. While you agonized
over every line of code making sure it was portable, they sold one
million copies of their software. They're now living on a private
island in the Pacific. You're still stuck playing language lawyer on
your source code.

I kid! I kid!

 

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

Making the new int type at best a convenience.


Rather than "on all implementations", where, oh, int and char will
continue to work.

Yes: it will also start working on implementations where int and char
don't work, but some other type does.

 

[Keith Thompson]

[snips]

If writing a typedef will do the job, then so will the new int type.

Making the new int type at best a convenience.

And what's wrong with convenience?

It's trivial to write your own abs() function. Should it not have
been standardized?

Rather than "on all implementations", where, oh, int and char will
continue to work.

No, int and char will *not* work if you require a type of exactly a
specified size.

Again, exactly my point. What _could have been_ a wonderfully useful
notion has instead become little more than a way to limit the portability
of the code.

No, it's a way to simplify code that's *already* inherently not 100%
portable. Code that *properly* uses the exact-width types is no less
portable than it would have been without them.

 

[pete]

Kind of. The TCs formally amend the Standard. The powers-that-be are
entitled to ask the technical committee at any time to provide a revised
copy of the Standard for publication instead of and/or in addition to a
TC document. N1124 is a draft of what that revised copy might look
like, should it be requested. That document would be a new (third)
edition of the standard that cancels and replaces the current second
edition (C99) and thus would have a new designation (e.g., C07).


The formal TC documents are generally available electronically at no
charge. You don't get the next edition of the Standard for free any
more than you get subsequent editions of any other book for free. (But
you *do* get the drafts for free!)

This might be a good place to note that N1256, an updated draft
incorporating the new TC3, has just been published:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

Thank you.

 

[Francine.Neary]

The problem with most "religious" debates is the zealots can always
quote a verse (usually out of context) and ignore the bigger picture.

The paragraph in the draft you are looking at may be identical to the
one in the ratified standard BUT other paragraphs in the standard, but
not in the draft, may alter the use of the one paragraph you have
quoted.

In high integrity, safety critical or other controlled development
environments (IS) 9K, CMM etc using an uncontrolled document ie a draft
can get you sacked. And rightly so.

I have as much respect for clc as anyone, but can winning an argument
here really be described as safety critical?

 

[pete]

Flash Gordon wrote:

Portability is not binary.

That's right.
It's defined in terms of "little or no modification".


ISO/IEC 2382-l : 1993

01.04.06
portability (of a program)
The capability of a program to be executed on various types
of data processing systems without converting the program
to a different language and with little or no modification.

 

[Kelsey Bjarnason]

No, you lost.

Someone else did it in 1/4 the time, because they used a sane language
with fixed size primitives in the first place. While you agonized
over every line of code making sure it was portable, they sold one
million copies of their software. They're now living on a private
island in the Pacific. You're still stuck playing language lawyer on
your source code.

Bah. Do it all in PHP and forget all the hassles.

I kid! I kid!

Indeed. Still... there's obviously (IMO at least) a problem, but what
really bothers me is that it seems to be a problem introduced by a
solution in search of a problem.

Ah well.

I took one look at these int types more'n a few years back, concluded then
that they were bogus nonsense and haven't seen anything in the most of a
decade since to change that opinion. If they work for others, fine. They
don't work for me.

 

[Keith Thompson]

That's right.
It's defined in terms of "little or no modification".


ISO/IEC 2382-l : 1993

01.04.06
portability (of a program)
The capability of a program to be executed on various types
of data processing systems without converting the program
to a different language and with little or no modification.

Note the phrase "various types of data processing systems". A C
program can be "portable" under this definition if it works with
little or no modification on some subset of conforming C
implementations, even if it doesn't work under all conforming C
implementations -- for example, if it works only under conforming C
implementations that provide a predefined integer type that's exactly
32 bits wide.

 

[Richard Heathfield]

Chris Hills said:

Joachim Schmitz wrote:

We had better stop before the The One True Faith of Forth joins in

Oh, have they finally finished painting it?

 

[Richard Heathfield]

Flash Gordon said:

I have not been following who thinks what as carefully as I might.

It shouldn't actually matter, should it?

There is a tendency on Usenet (and, I think, in life in general) to
divide the world into teams, such that if I agree with X about Y, then
it is assumed by (some) others that all of my opinions about Y are the
same as X's opinions about Y. But this is simply not the case, and
there is no reason why it should be.

I agree with Kelsey that intN_t types are completely and utterly useless
(wait, wait!). I also agree with Kelsey that it's no big deal quoting
from a draft in clc. But I am less bullish than Kelsey about other
people using intN_t. Personally, I think it's a mistake to be led down
that path, but hey, maybe - just *maybe* - there's a real use for these
little critters that I haven't thought of, yeah? And some people whose
opinion I respect have suggested that they do in fact find these types
useful. So, even though they seem completely useless *to me*, and even
though I think they are ugly and unnecessary warts, I'm not about to
insist that they're dropped from the language. If they are useful to my
friends, let them stay, warts and all.

<snip>

 

[Joachim Schmitz]

Cool, thanks!

Is TC3 itself available? (I got TC1 and TC2 as free downloads from
webstore.ansi.org, but TC3 isn't there yet.)

I think I found it:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1235.pdf

Bye, Jojo

 

[Charlie Gordon]

For purposes of calculation they could. Probably even for purposes of
satisfying the standard. But there might be times when you actually
need the hardware to be able to write say 16 bits and no more, such as
for writing to a 16-bit memory mapped port, where the adjacent 16 bits
is a different port.

You can't really do that portably. If you need bit addressability to your
hardware, you are beyond the scope of the C language.

They are?

Can you name counter examples ?

Aside from the DS9000 and some surviving Unisys mainframes, no one came up
with real life examples of contemporary architectures with non
twos-complement arithmetics, padding bits, trap values and similar obsolete
crap.

 

[Charlie Gordon]

"Keith Thompson" <[email protected]> a écrit dans le message de (e-mail address removed)... [...]

How would you emulate uint8_t (which, remember, must have no padding
bits) on an implementation with CHAR_BIT==9, which therefore cannot
support 8-bit objects?

You do not emulate its representation, but you can emulate its well
defined
arithmetic behaviour with available hardware operations and appropriate
masks, shifts, etc. The compiler is already doing something very similar
for bitfields.

And what if I want to write exactly 8 bits to a binary file?

You cannot write bits to a file, you write bytes.
If your byte is larger than 8 bits, my proposal does not solve you problem,
but helps in producing values that are limited to the 8 bit range without
the need for explicit bit masks.

 

[Charlie Gordon]

[...]
How would you emulate uint8_t (which, remember, must have no padding
bits) on an implementation with CHAR_BIT==9, which therefore cannot
support 8-bit objects?

You do not emulate its representation, but you can emulate its well
defined
arithmetic behaviour with available hardware operations and appropriate
masks, shifts, etc. The compiler is already doing something very similar
for bitfields.

Arithmetic isn't everything.

Arithmetic can by relied upon more readily than representation.

 

[Philip Potter]

[snips]

You keep saying that. The new types *are* required to exist

Really? So uint8_t exists on a machine with 64-bit char and short and int
and long? No, it doesn't. Continuing...

Please stop arguing against statements which people aren't making. It just
decreases the signal-to-noise ratio.

"If". And if it doesn't, they don't exist.

Exactly my point. So we're all agreed. Good.

So I now have new int types which, as I keep - correctly - stating aren't
required to exist, so that using them means portability goes straight down
the crapper.

We *are* all in agreement on this, right?

You're treating this like every program is required to compile on every
implmentation, and you're portraying portability as a binary property.

strcmp("a","b") isn't required to equal strcmp("b","c") but code has been
written which relies on this. Such code is not portable to all conforming hosted
implementations. I wouldn't say portability has gone "down the crapper", though,
because in the real world away from DeathStations 9000, almost all character
sets are in alphabetical order.

Similarly, code which uses an exact-width type is not portable to all conforming
hosted implementations. Portability is reduced (Yes! We're agreed here!) but
hasn't gone "down the crapper" - a phrase which I take to mean "portability is
reduced to the point where it's no longer useful".

 

[Keith Thompson]

Can you name counter examples ?

Aside from the DS9000 and some surviving Unisys mainframes, no one
came up with real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

If I recall correctly, some Cray vector machines have padding bits in
some of their predefined integer types. I haven't had a chance to
play with Cray's newer systems, so I don't know whether this is still
applicable; the systems I'm familiar with are mostly obsolete.

 

[jacob navia]

If I recall correctly, some Cray vector machines have padding bits in
some of their predefined integer types. I haven't had a chance to
play with Cray's newer systems, so I don't know whether this is still
applicable; the systems I'm familiar with are mostly obsolete.

Well, this confirms the proposition that there are no

 

[lawrence.jones]

Is TC3 itself available? (I got TC1 and TC2 as free downloads from
webstore.ansi.org, but TC3 isn't there yet.)

The official version is wending its way through the system and will be
available from ISO, ANSI, and other standards organizations in due
course. In the meantime, as noted elsethread, N1235 is what was
submitted for publication and is available from the committee's web
site:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1235.pdf>

-Larry Jones

Do you think God lets you plea bargain? -- Calvin

 

[Keith Thompson]

Well, this confirms the proposition that there are no

No, it doesn't. As I indicated, I don't know whether Cray's newer
systems have integer types with padding bits, so the question is still
open.