Sizes of Integer Types

[Richard Heathfield]

Kelsey Bjarnason said:

Already did. Pay attention.

Both Ian and Kelsey are bright bunnies. I wish they could both conduct
this debate with a little more respect for each other.

Come on, guys - lighten up a little. Demonstrate that it's possible to
disagree with someone without insulting them.

<snip>

 

[pete]

Kelsey Bjarnason wrote:

Unless you use them, at which point your code's portability has gone
straight into the crapper. Yay, C!
Yesterday you were portable across
endless systems, now you're portable across... well...
who the hell knows, because all bets are off.

Now you're portable across implementations that support those types.
Without the standardization of the optional types,
then you would not even be portable across those.

That was explained to me, a long time ago, by one of the smart guys,
either on this newsgroup or comp.std.c

Personally, I value the relative simplicity of the C89 standard.

 

[Charlie Gordon]

I make several of the standard I use. Others I buy. Some are expensive. So
are some tools and test suites. That is the same in any industry.

All ECMA Standards can be downloaded from their site at no cost.

ISO charging the same for pdf files and hard bound copies is ludicrous.
Charging people for knowledge produced by benevolent contributors and people
paid directly or indirectly by government agencies is a rip off, Charging
for printing costs is a different matter.
It is about time ISO and the various national standards bodies that
contribute moved into the XXIst century.

ISO charges 400 USD for the right to download and use one copy of the ISO-C
pdf file.
ANSI charges about 20 USD for the very same document.

Let me prove how scandalous this is: if a NYC yellow cab driver charges 400
USD for 15 minute trip inside Manhattan, you take him to court, and he will
be convicted of fraud.

While the 20 USD charged by ANSI does not seem extravagant, they are still
largely unwarranted.

How would you feel if a surgeon was operating on you using a draft
procedure rather than the certified procedure because the certified one
costs money?

bad example : surgeon procedures tend not to be patented nor copyrighted.
As such they don't cost money. What costs money in this area are tools and
training, both of which have a high marginal cost. Furthermore, the
surgeon's skill and experience matter more than the status of the procedure
he is using.

 

[Keith Thompson]

Not at all. The draft is useful because it combines ISO/IEC 9899:1999
and the Technical Corrigenda in one easily searchable document.

I've lost track of which draft we're talking about.

N1124 is the post-C99 draft you're referring to; it combines the C99
standard with TC1 and TC2, with all differences from the official C99
marked by change bars. That's what I use most of the time. It's
possible that some unmarked wording in N1124 differs from the
corresponding wording in the C99 standard, but I doubt it, and I'm
willing to assume that they're consistent (particularly if I'm posting
to comp.lang.c rather than implementing a compiler).

If I post a quotation from N1124, and it's not marked with a change
bar, I generally don't bother to mention that I used N1124 rather than
the C99 standard, even though I have copies of both. In my opinion
it's more likely that I'll misquote it myself through a copy-and-paste
error than that there's an unmarked discrepancy between the C99
standard and N1124. In a more critical context, I'd likely check
both, but I've never even heard of an error in N1124; if I ever found
one, I'd post it to comp.std.c.

N869 is a pre-C99 draft that's still used by some people. One
advantage, apparently, is that it's available as plain text as well as
in PDF form. I suggest that anyone posting quotations from N869
should identify them as such, since there are things that changed
between N869 and C99, and they're not marked in either document.

 

[Keith Thompson]

[snips]

Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.

Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

uint32_t isn't defined on an implementation that has no predefined
32-bit integer type. Good, you agree with me.

Are you *deliberately* missing the point?

 

[Keith Thompson]

"Harald van D?k" <[email protected]> a écrit dans le message de
[email protected]... [...]

int8_t, int16_t, int32_t, int64_t and the corresponding unsigned integer
types are required on systems where there exist types matching the
descriptions. This means that on C99 implementations where they're not
defined, it wouldn't be possible to use some other type as a substitute
anyway, unless you didn't really need an exact-width integer type in the
first place.

It would have been good to mandate their support on _all_ architectures.
Odd bit sized and non 2's complement machines could emulate them in
software...
Such biests are disappearing fast at this time, and lack of complete c99
support for them would not have hurt anybody.

Definitely something to remember for the next release.

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?

 

[pete]

Keith Thompson wrote:

N1124 is the post-C99 draft you're referring to; it combines the C99
standard with TC1 and TC2, with all differences from the official C99
marked by change bars.

What is N1124 a draft of?

 

[Keith Thompson]

What is N1124 a draft of?

The Committee. semi }

The header on each page says:

WG14/N1124 Committee Draft -- May 6, 2005 ISO/IEC 9899:TC2

I suppose it could be considered to be a draft of the next version of
the C standard.

If that's really a serious question, comp.std.c would be the place to
ask it.

 

[Ian Collins]

[snips]

On Wed, 12 Sep 2007 20:31:56 +1200, Ian Collins wrote:

If your code is processing a stream of say 16 bit data, you can either
assume the existence of a 16 (or 8) bit type
Like char and short? Oh, they're not required to be 8 and 16 bits, just
at least 8 and 16 bits. Meaning we've had perfectly good types for this
sort of thing since what, K&R?

So what would you rather have, code using short that compiles happily on
a system where short is 32 or 18 bits, but then fails to work (possibly
in a less than obvious way) or code that uses int16_t and won't compile?

I'd rather have code that compiles and works. Maybe that means masking,
fine, I can live with that if I have to. At least I'd only have one code
path to maintain, and it would work on _any_ conforming implementation.

But what would you call your 16 bit type?

 

[Ian Collins]

Kelsey Bjarnason said:

Both Ian and Kelsey are bright bunnies. I wish they could both conduct
this debate with a little more respect for each other.

Come on, guys - lighten up a little. Demonstrate that it's possible to
disagree with someone without insulting them.

I haven't, I've just stated the plain truth, x86, SPARC and PPC are in
no way close equivalents.

 

[Ian Collins]

[snips]

That's gone from nonsense to total bollocks. Kindly show how PPC or
SPARC are "close equivalents" to x86.

Already did. Pay attention.
Where?

As I said before, if the system does have a native 8 bit type, just add
the typedef, if not, you can't use it. The existence of the C99
typedefs changes nothing in this regard.

Unless you use them, at which point your code's portability has gone
straight into the crapper. Yay, C! Yesterday you were portable across
endless systems, now you're portable across... well... who the hell knows,
because all bets are off. An absolute *leap* ahead, right into the 16th
century.

If your application requires fixed width types, your application
requires fixed with types. Why should giving them a standardised name
make you code less portable? The fixed width requirement has already
restricted its portability.

 

[CBFalconer]

Kelsey Bjarnason wrote:
.... snip ...

If your application requires fixed width types, your application
requires fixed with types. Why should giving them a standardised
name make you code less portable? The fixed width requirement
has already restricted its portability.

The problem, as I see it, is twofold. First, many 'programmers'
are using those fixed width types arbitrarily, without any need,
and thus making their code non-portable. Secondly, I don't really
see any reason for requiring them anywhere. At most the i/o path
to/from something is truncated to some fixed bit count. I may be
mistaken here.

 

[CBFalconer]

Good. Show me where this is defined on a machine with 64-bit
types. Whoops. Doesn't exist. Next.

Seems to me that anything that may require chopping off of high
order bits should be an unsigned quantity in the first place.

 

[CBFalconer]

What is N1124 a draft of?

Please closely examine the above quote from Keith Thompson, and
attempt to detect an underlining.

 

[Richard Heathfield]

Ian Collins said:

I haven't, I've just stated the plain truth, x86, SPARC and PPC are in
no way close equivalents.

I am happy to accept your claim that you have spoken truth, but I cannot
agree that it was either just or plain. See above quote of your words.
(I deliberately quoted /both/ insults, yours as well as his.)

Anyway, I've said my bit, and now I'm shutting up. Please don't treat
Kelsey as an enemy (and vice versa). You're both too smart for that.

 

[Richard Bos]

As some one involved in 2 ISO, 1 IEC and and other international
standard I can tell you that you only work from released standards.
quoting from arbitrary drafts is pointless and has no validity.

As someone involved in 2 ISO, 1 IEC, and other international standards
(none, apparently, on grammar), you should know better than to think
that n1124.pdf is an _arbitrary_ draft.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ (e-mail address removed) www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Fix yer sig.

Richard

 

[Richard Heathfield]

CBFalconer said:

Please closely examine the above quote from Keith Thompson, and
attempt to detect an underlining.

Keith's words (above) do not indicate what N1124 is a draft of. They
merely indicate that it is a draft, and give further information about
the origin of its contents.

To answer pete's question: Yet Another Dead Duck.

 

[Ian Collins]

The problem, as I see it, is twofold. First, many 'programmers'
are using those fixed width types arbitrarily, without any need,
and thus making their code non-portable.
Agreed.

Secondly, I don't really
see any reason for requiring them anywhere. At most the i/o path
to/from something is truncated to some fixed bit count. I may be
mistaken here.

All of my C these says is either embedded or drivers, where size does
matter.

Over the past 20 odd years of embedded development I must have seen
dozens of different typedefs or defines for fixed width types, including
such abominations as WORD. So I was really pleased to see the language
standard define a standard naming convention that enables us to consign
this mishmash to history.

 

[Flash Gordon]

Kelsey Bjarnason wrote, On 13/09/07 00:50:

[snips]

That's gone from nonsense to total bollocks. Kindly show how PPC or
SPARC are "close equivalents" to x86.

Already did. Pay attention.

Processors with completely different instruction sets AND different HW
interfaces to other devices are not "close equivalents". AMD processors
are close equivalents of x86 processors, but the PPC and SPARC are not.

Unless you use them, at which point your code's portability has gone
straight into the crapper.

If the code DEPENDS on using an exactly 8 bit type then you have lost
nothing, because YOU DID NOT HAVE PORTABILITY TO ALL SYSTEMS in the
first place.

Yay, C! Yesterday you were portable across
endless systems,

No you were NOT. The code already depended on having an exact 8 bit type
so was not portable to machines without one.

now you're portable across... well... who the hell knows,
because all bets are off.

Exactly NO bets are off. You are EXACTLY portable to ALL machines with
the type your code depended on in any case, the difference is that you
know it will not compile on all those machines it would never have
worked on anyway.

An absolute *leap* ahead, right into the 16th
century.

Gah.

Personally I consider getting rid of a mess of conditional defines and
making it easier to meet some serious requirements a step forwards.

 

[Flash Gordon]

Kelsey Bjarnason wrote, On 13/09/07 00:47:

[snips]

On Wed, 12 Sep 2007 20:31:56 +1200, Ian Collins wrote:

If your code is processing a stream of say 16 bit data, you can either
assume the existence of a 16 (or 8) bit type
Like char and short? Oh, they're not required to be 8 and 16 bits, just
at least 8 and 16 bits. Meaning we've had perfectly good types for this
sort of thing since what, K&R?

So what would you rather have, code using short that compiles happily on
a system where short is 32 or 18 bits, but then fails to work (possibly
in a less than obvious way) or code that uses int16_t and won't compile?

I'd rather have code that compiles and works. Maybe that means masking,
fine, I can live with that if I have to.

Sometimes you would have to do a lot more than that, and you would be
doing it on a significant portion of the lines of code or doing a lot of
work to PROVE that you could get away without it.

Personally I prefer NOT to spend major effort on things which are
explicitly NOT a requirement.

At least I'd only have one code
path to maintain,

Those of us using uint16_t only have one code path because the code is
only required to work on platforms with a 16 bit unsigned integer type
without padding. We don't have to go through nests of conditional
compilation to mate it work.

Do you REALLY find so hard to understand that some code does not have to
be portable to every system? Will ALL of your code run on a system with
16 bit char, short and int with only 8K of space for the program and 8K
of space for data?

and it would work on _any_ conforming implementation.

So will ALL of your programs fit in to 8K of program space and 8K of
data space? I've spent a LOT of time programming for such systems,
although I don't now. However, back when I did the SW I wrote to process
live video definitely would NOT have fitted on such a small architecture
because it needed space for an entire frame of video, and it needed it
all in RAM for speed. Oh, and the processors on the small systems would
not be anywhere near fast enough. The code I currently work on requires
a few MB of program space, so also would not fit, and that is all code
REQUIRED to do the job.

NOW do you get that some code is not required to run on ANY conforming
implementations? Do you get that even YOU could not write code to solve
some problems that would run CORRECTLY on ANY conforming implementation?

We ALL accept restrictions in portability. It might be restricted to
only hosted implementations because it uses stdio. It might be
restricted to only implementations with more than the minimum of memory.
It might be restricted to only implementations with a networking (give
me a driver for a specific NIC that will work on a machine without ANY
NIC). Or it might be restricted to only implementations with a 16 bit
integer type with no risk of wanting it to run on a CRAY because you are
not going to get a CRAY installed in a fighter jet or a mobile phone.