Standard integer types vs <stdint.h> types

[Army1987]

If I write

int a = 45000;

[...]
Even on a 16 bit machine where int is the same as a pointer and memory
space is flat? You appear to have contradicted yourself.

The program in this case exceeds the capaciticites of the machine. Of
course you can write any program to farm out data to backing store and
thus run on any machine whatsoever, but it is seldom sensible to do so.

Obviously if the number 45000 doesn't refer to a count of things in
memory the logic won't hold.

Obviously if the number 45000 referred to a count of things in memory it
wouldn't be placed in a signed int.
Just an example:
Supposing ERANGE is 34, if you write errno = ERANGE; there are 34 of
*which*, exactly, in memory?

 

[Harald van Dijk]

So what? The language (C90) doesn't access them. It does access short,
int, long.

You're essentially arguing against a claim that C90 implementations that
provide <stdint.h> as an extension, provide <stdint.h>. Sure, the C90
standard doesn't define what a C90 implementation might define in
<stdint.h>, but if the only C99 dependency of code is <stdint.h>, and the
C90 implementation's extension is compatible with C99's standard header,
then the code will still work as intended.

 

[Malcolm McLean]

Obviously if the number 45000 referred to a count of things in memory it
wouldn't be placed in a signed int.

Intermediate counts might be negative. For instance we might need more than
10 - 1 per site employees to comply with some regulation. If we have eleven
sites, we need to check that 45000 is greater than -1, which in this case it
comfortably is, as long as you use signed arithmetic. You will very
frequently see int used to hold a count of things in memory in production
code, and frequently it is the right choice.

Just an example:
Supposing ERANGE is 34, if you write errno = ERANGE; there are 34 of
*which*, exactly, in memory?

Not all integers count things in memory. In this case a perfectly reasonable
strategy would be to number the errors consecutively and use the number to
index into an array of messages, but in fact the C standard hasn't imposed
that.

 

[James Kuyper]

No, because the contents of stdint.h are optional, ...

No, only some of the contents are optional; others are mandatory. The
int_fastN_t and int_leastN_t types are all mandatory for N = 8,
16, 32, and 64, and so are intmax_t. For each mandatory type, the
corresponding macros are also mandatory. For each type not supported,
the corresponding macros are prohibited, which provides an easy way to
perform a compile-time check of which types are supported.

... and you have to
pick one that is both suitable and present. If the machine doesn't
have a suitable type they aren't there.

Oddly enough, when an optional type is not supported, it generally
wouldn't do you much good if the corresponding typedef were provided,
would it? The typedef couldn't actually be used, because the
corresponding type couldn't be implemented. Making it mandatory to
support the actual types would serve only to prohibit conforming
implementations of C on platforms where those types couldn't be
efficiently supported, it would not increase the number of platforms
supporting those types. There's no good reason for an implementation to

... However the types are all
aliases for something in the byte, short, int, long, long long (and
unsigned) group.

No, it is permitted for them to be aliases for extended integer types as
well.

Use of limits.h allows you to select the optimum
for your situation at compile time, and set an equivalent.
Something like:

#if INT_MAX >= 214748367
# define THETYPE int
#else
# define THETYPE long
#endif

Note: in principle, at least, you should be checking INT_MIN as well as
INT_MAX; there is no guaranteed relationship between the two values, and
unless your application is better served by an unsigned type, INT_MIN
should be at least as relevant as INT_MAX.

If your limit does not correspond to the mandatory int_leastN_t
types, then there's some advantage to this approach. When your limit
does correspond to one of those values, (as it does in this case), then
THETYPE should be the same, as the corresponding int_least type, unless
that type is an extended type that's smaller than THETYPE, which
presumably makes it preferable, while still being big enough for your
needs. Why would you prefer THETYPE instead?

and now the rest of the code only sees the standard types (and
THETYPE). You also have the side benefit of not needing C99,
because C90 will work just fine.

That is a real advantage, given the slow adoption of C99. However,
<stdint.h> is by far one of the easiest of C99's changes to implement,
and it should be implemented by any compiler which has even minimal
support for C99, and it can easily be supported as an extension to C90
implementations.

Even for implementations which don't provide it, there are publicly
available versions of stdint.h that can be used in a C90 context that do
essentially the same thing as your code, thereby allowing you to write
code that will not need that crutch when compiled using implementations
that do natively support <stdint.h>, whether or not they support any
other feature of C99.

 

[Richard]

Well, the thing that makes C code portable is adherance to the C
standard. Since POSIX doesn't really appear there, POSIX dependant
code is not as portable as C code. This group deals with portable
C code. If we fail to advise OT posters of their mistakes, they
will never learn, and the OT posts will run wild.

I believe other groups exist where POSIX is topical.

Why don't you butt out of threads to which you offer no input? Ian was
explaining something to someone. It does not need to be vetted by
you. Now, run along about to your thread about cleaning cat litter. I
mean! That is surely on topic because it's YOUR thread eh?

 

[Paul Hsieh]

Paul Hsieh said:


If that is true, then all integers are floating point numbers. You might
consider it worthwhile to indulge in such sophistry, but you just lost my
attention.

Sophistry?!?!

I gave a very specific real example that people should probably pay
attention to. If you want to implement a concept of universal timer
in C how are you going to do it? Using 32 bits to count seconds since
1970 doesn't work past 2038 or for historical records before 1902 --
that's not even good enough for young earth creationists! Older 16
bit compilers just don't support 64 bit, so you can't hope to finagle
some kind of platform specific 64 bit support for them.

But even Turbo C supports double precision floating point. That means
we have 53 bits widely available for universal computations. It
supports the widest possible range of compilers, and also has the
bonus of allowing you to measure milliseconds or microseconds as well
(using the fractional part). All the mktime() class of functions
still treat the offset as an integer, and in fact, has to do a lot of
integer math on them. But you can add in all the precision timers in
your system into a single unified concept of time.

This is not a joke or some marginal example. This is the best way of
supporting universal time in the C language. If this reasoning
escapes you, that's got nothing to do with how or what I am arguing.
That just has to do with you.

The C language standard even provides an existing rationale for
modf(), and its for reasons like this. Its for performing integer
math on floating point.

How nice. I'm not quite sure what's so esoteric about cryptography, and I
have found my bignum library to be perfectly adequate for algorithms such
as Diffie-Hellman RSA, which need pretty vast numbers if they're to be any
use.

Vast? Clearly you are using some strange non-practical version of RSA
or something. From my understanding of real world cryptography, you
generally never go above about 4K bits, which is pretty tiny by big
integer standards. You barely even get to the point of invoking any
of the advanced methods for performing multiplies.

In any event, I didn't claim cryptography was esoteric, I claim that
the other things I do with it are esoteric (like a symbolic math thing
I was working on.)

Anyway, like I said, I'm out. If you want to discuss floating point in an
integer context, that's up to you, but I have more productive ways to
spend my time (like, for example, drinking coffee).

Well, its one thing to ignore your hardware's capabilities because you
compiler can't support it. But I don't what to think when you ignore
its standards compliant support when it *DOES* support the native
hardware.

 

[Ian Collins]

So what? The language (C90) doesn't access them. It does access
short, int, long.

But the programmer can in a C90 program.

What are you arguing against?

 

[Ian Collins]

Well, the thing that makes C code portable is adherance to the C
standard. Since POSIX doesn't really appear there, POSIX dependant
code is not as portable as C code. This group deals with portable
C code. If we fail to advise OT posters of their mistakes, they
will never learn, and the OT posts will run wild.

This is pointless nonsense.

I was explaining how I choose to use 64 bit types, I was not discussing
POSIX.

 

[Ian Collins]

Then problem with your approach is that you then need to test the code
on two systems. With Richard's, you can develop on your humble PC, even
my horrid Vista system, and know that the results ought to be the same
on the Cray or anything else.

How so? If a platform is not explicitly listed as having 64 bit types,
the result is exactly the same as Richard's approach.

If it is, the chance of an unexpected bug is greatly reduced, because
the emulation library is not used. Where do think bugs will be, in the
processor's 64 bit instructions, or an emulation library?

 

[Richard Heathfield]

Paul Hsieh said:

Sophistry?!?!

Not only sophistry, but demonstrably false sophistry.

Claim: floating point is a superset of integers;
Consequence: all integers are floating point numbers;
Counter-example: int n = 42; printf(var?"%f\n":"%Lf\n", n);
Behaviour: undefined, because %f requires a double argument (or a float
argument which will be promoted to double), but an int argument is
supplied - and %Lf requires a long double argument, but an int argument is
supplied;
Conclusion: ints are not floats (which would be promoted to double in a
printf call) or doubles or long doubles, and therefore are not floating
point types;
Demonstrandum: QE.

 

[Richard Harter]

Paul Hsieh said:


Not only sophistry, but demonstrably false sophistry.

Claim: floating point is a superset of integers;
Consequence: all integers are floating point numbers;
Counter-example: int n = 42; printf(var?"%f\n":"%Lf\n", n);
Behaviour: undefined, because %f requires a double argument (or a float
argument which will be promoted to double), but an int argument is
supplied - and %Lf requires a long double argument, but an int argument is
supplied;
Conclusion: ints are not floats (which would be promoted to double in a
printf call) or doubles or long doubles, and therefore are not floating
point types;
Demonstrandum: QE.

Er, he didn't say that ints are floats, ergo your demonstration
doesn't falsify what he did say. He said, and I quote "Floating
point is a superset of integers". You responded with, "If that
is true, then all integers are floating point numbers." His
statement, and your statement refer to numbers, which is a
mathematical concept, and not to C number types. It will not do
to say that you were talking about number types - if you mean to
be pedantic then you need to carry it through.

 

[Richard Heathfield]

Richard Harter said:

He said, and I quote "Floating
point is a superset of integers". You responded with, "If that
is true, then all integers are floating point numbers." His
statement, and your statement refer to numbers, which is a
mathematical concept, and not to C number types.

This is comp.lang.c, and the thread title is "Standard integer types vs
<stdint.h> types". The context could not be clearer.

 

[jacob navia]

Paul Hsieh said:


Not only sophistry, but demonstrably false sophistry.

Claim: floating point is a superset of integers;
Consequence: all integers are floating point numbers;
Counter-example: int n = 42; printf(var?"%f\n":"%Lf\n", n);
Behaviour: undefined, because %f requires a double argument (or a float
argument which will be promoted to double), but an int argument is
supplied - and %Lf requires a long double argument, but an int argument is
supplied;
Conclusion: ints are not floats (which would be promoted to double in a
printf call) or doubles or long doubles, and therefore are not floating
point types;
Demonstrandum: QE.

I think the above nonsense breaks the record for c.l.c and that
is difficult to do !

with sizeof(int)==4 all 32 bit integers can be exactly represented in
a double. The integers are a subset of floating point.

In mathematics too, N is a subset of R.

 

[dj3vande]

Richard Harter said:



This is comp.lang.c, and the thread title is "Standard integer types vs
<stdint.h> types". The context could not be clearer.

In a mathematical context, it's quite common to hear mathematicians
making claims like "the reals are a superset of the rationals".

Except they're not; the rationals are equivalence classes over ordered
pairs of integers, and the reals are sets of rationals[1], so no
rational number can possibly be a real number. This doesn't keep it
from being understood as "the rationals are isomorphic to a subset of
the reals", for both the person making the claim and the person hearing
it.

It seems to have been clear (to everybody but you) that the original
claim was intended to be taken this way, and not to claim that the
representation is identical. It turns out that even then the claim is
wrong (division breaks the isomorphism, and on most implementations
it's trivial to find an integer type and a floating point type such
that the floating point type can't even represent all the values that
the integer type can), but the difference in representation is
irrelevant to that.


dave

[1] Sometimes. There are several equivalent constructions, but these
are the ones that I saw in my math courses.
But, as far as I know, it's impossible to construct the reals in a
way that makes them look the same as the rationals, which is my
point here.

 

[Richard Harter]

Richard Harter said:



This is comp.lang.c, and the thread title is "Standard integer types vs
<stdint.h> types". The context could not be clearer.

That, sir, is mere sophistry. You've been arguing too long with
He Who Shall Not Be Named.

 

[jacob navia]

Er, he didn't say that ints are floats, ergo your demonstration
doesn't falsify what he did say. He said, and I quote "Floating
point is a superset of integers". You responded with, "If that
is true, then all integers are floating point numbers." His
statement, and your statement refer to numbers, which is a
mathematical concept, and not to C number types. It will not do
to say that you were talking about number types - if you mean to
be pedantic then you need to carry it through.

In maths N is a subset of R, by the way.

 

[Richard Heathfield]

jacob navia said:

I think the above nonsense breaks the record for c.l.c and that
is difficult to do !

I think you're mistaken.

with sizeof(int)==4 all 32 bit integers can be exactly represented in
a double.

Firstly, C does not require sizeof(int)==4. Secondly, C does not require
that a byte has eight bits. If CHAR_BIT is 32 and sizeof(int) is 4, for
example, then ints will have not 32 but 128 bits. An implementation is
certainly free to set doubles and long doubles at, say, 64 bits and ints
at 128 bits. On such systems, it is impossible precisely to represent all
int values as doubles or long doubles.

The integers are a subset of floating point.

For that to be true, integer types would have to be floating-point types,
which they are not. See above.

In mathematics too, N is a subset of R.

We are discussing C, not mathematics.

 

[CBFalconer]

But the programmer can in a C90 program.

What are you arguing against?

Using object types that are not universally available on any
machine, thus impeding portability. limits.h allows you to
automatically select a suitable type from short, int, long (maybe
long long) at compile time. The objective is suitable size with
minimum complexity.

 

[CBFalconer]

Paul Hsieh said:

Not only sophistry, but demonstrably false sophistry.

Oh come on now. Mr Hsieh just demonstrated a way of securing an
object that could be processed by arithmetic instructions and carry
53 bits of integer information on most extant systems. If you
create your own type (possibly an array of two ints) you will have
to create the arithmetic functional procedures, and conversion
methods for i/o. Instead of:

a += b;
you need:
addup(thing *a, thing b);
and so forth.

 

[Paul Hsieh]

In a mathematical context, it's quite common to hear mathematicians
making claims like "the reals are a superset of the rationals".

Just to make it clear, I did not say "real" I said "float". There is
a difference, and I was *NOT* making a direct appeal to any special
mathematics outside the scope of the C language. The set of integers,
their properties, and operations in the *C LANGUAGE* are directly
translatable into floating point (floats or doubles, but obviously I
am interested in doubles here) in the *C LANGUAGE* with the relevant
difference being that the floating point formats can encode different
sizes.

*Richard* expanded the discussion beyond the topic by making blanket
statements about integers that were just wrong. I took the
invitation, kept the discussion narrowed on the topic integers in the
C language, but beyond what is in stdint.h and demonstrated Richard's
error *WITHOUT* expanding the context. If the extension to floating
point bothers you, then ask yourself why EOF gets tacked onto the
output of fgetc() by extending from unsigned chars to ints. Extending
types into other types, is a standard practice in C.

Except they're not; the rationals are equivalence classes over ordered
pairs of integers, and the reals are sets of rationals[1], so no
rational number can possibly be a real number. This doesn't keep it
from being understood as "the rationals are isomorphic to a subset of
the reals", for both the person making the claim and the person hearing
it.

Uh ... its not just an isomorphism, its a bijection complete with all
the operations. They are indistinguishable. The core definitions/
axioms for integers are *satisfied* by the integer subset of the
reals. Claiming they are different is like claiming C doesn't have a
stack. It helps if you think of axioms as properties, not as private
wells from which its special manna becomes magically branded by those
axioms. Whatever, this is *actually* (uncontroversially for once) off
topic; try sci.math .

It seems to have been clear (to everybody but you) that the original
claim was intended to be taken this way, and not to claim that the
representation is identical.

His response is actually quite sad. Knowing that you can have this
extended (if not exactly convenient) integer implementation in C is
kind of useful at times when 32 bits just isn't enough, but you need
more portability that systems that implement 64 bits. He seems dead
set against acknowledging this fact. Perhaps restricting himself to
the C standard just isn't enough; he's got to restrict himself even
more.

[...] It turns out that even then the claim is
wrong (division breaks the isomorphism, and on most implementations
it's trivial to find an integer type and a floating point type such
that the floating point type can't even represent all the values that
the integer type can), but the difference in representation is
irrelevant to that.

I'm not making an argument about representation. Go back through this
thread and notice that I make specific mention of the modf()
function. This allows you to implement integer division and modulo on
floating point numbers. In other words, you have a *true* integer in
floating point implementation in C, and you need not go any further
than the standard library.