Standard integer types vs <stdint.h> types

D

dj3vande

Flash Gordon said:

Is ugliness a problem? I guess ugliness is in the eye of the beholder.

For exact-width types, I actually lean toward considering ugliness a
Good Thing.

Most people who think they need exact-width types are wrong, and making
them as ugly and inconvenient as possible discourages their use (which
on the whole is a Good Thing); but when you actually do need them (I've
recently written otherwise- portable code that does, to handle
serializing and deserializing data structures for storage in files
(portably) or transmission over a network (system-specific)), it's
rather nice to have standardized names rather than having to write (a
subset of) C99's <stdint.h> for every C90 implementation I want to
use.
(ntohl and htonl would be nice to have standardized for the same
reason, though some thought would have to be put into whether they work
on bytes, or octets, or low-octet-of-each-byte, or...)


dave
 
D

dj3vande

Paul Hsieh said:
Floating point is a superset of integers.

Counterexample:
--------
dj3vande@buttons:~/clc (0) $ cat fp-int.c
#include <stdio.h>

int main(void)
{
unsigned long in=-3;
float d=in;
unsigned long out=d;

if(in==out)
{
printf("unsigned long -> float -> unsigned long is not demonstrated to be\n lossy by this example\n");
}
else
{
printf("unsigned long -> float -> unsigned long is demonstrated to be\n lossy by this example\n");
}

printf("in: %lu\n",in);
printf("float val: %f\n",d);
printf("out: %lu\n",out);

return 0;
}
dj3vande@buttons:~/clc (0) $ gcc -W -Wall -ansi -pedantic -O fp-int.c
dj3vande@buttons:~/clc (0) $ ./a.out
unsigned long -> float -> unsigned long is demonstrated to be
lossy by this example
in: 4294967293
float val: 4294967296.000000
out: 4294967295
dj3vande@buttons:~/clc (0) $ gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
C

CBFalconer

Paul said:
.... snip ...


The way you determine if a 64 integer overflows on a 72 bit
machine is different from how you do it on a 64 bit machine (as
in, the code you write is different). If you want to just do it
one way, it is helpful if you have int64_t, not long long int.

I would suggest reading the appropriate copy of limits.h. In fact,
you can even, with great difficulty, get those values into your
program for examination. Also the compiler.
 
C

CBFalconer

Ian said:
Richard Heathfield wrote:
.... snip ...


Well the platforms I work on are either POSIX compliant, or I use
a POSIX wrapper over the native API, which provides stdint.h.

The last time I looked the C standard had absolutely no reference
to POSIX. If this was comp.os.posix your comment would have a good
chance of being on topic.

I take it back. It shows up in the bibliography. Once. Still OT.
 
I

Ian Collins

CBFalconer said:
How does that remove the need for a C99 compiler?
Because the *platform* will have the stdint.h types defined and any C
compiler on that platform will accept (either by implementing or
ignoring) the subset of C99 features the (POSIX) standard requires
(restrict for example).
Besides which,
this is c.l.c, and POSIX is not specified in any C standard that I
have seen.

I was replying to the assertion that a conforming C99 compiler is
required for the stdint.h types.
 
I

Ian Collins

CBFalconer said:
The last time I looked the C standard had absolutely no reference
to POSIX. If this was comp.os.posix your comment would have a good
chance of being on topic.

I take it back. It shows up in the bibliography. Once. Still OT.
Does every word posted here have to be in the ISO C standard to meet
with your approval? Read what I was answering.
 
W

William Pursell

This is the reasoning that has led me to conclude that the
int_(fast|least)N types are more useful than signed char and
[unsigned] (short|int|long|long long). They allow me to state my
entire intent instead of stating only half of it and hoping the other
half works out. Having types that allow me to say "I want the
(fastest|smallest) type that gives me at least N bits" is more useful
than having types that only allow me to say "I want a type that gives
me at least N bits".


When your intent is "I need a value that
holds an integer, and I don't care much about speed
or size", a plain int is ideal. Following
the advice that "pre-mature optimization is the root
of all evil", 99% of the time a programmer finds
themselves in that situation. uint_fast32_t is
great, but if I see it in code, I will assume that
it started life as an unsigned and was changed only
after a *lot* of performance testing indicated
that the change was warranted.

IMO, the int_(fast|least)N types should be
used sparingly, since their use implies
information about the performance characteristics
of the code.
 
P

Philip Potter

Richard said:
Paul Hsieh said:


Provided, of course, that you are one of those lucky people who has a
conforming C99 compiler. I am not one such.

I'm afraid even on a C99 compiler it's not guaranteed to work.

int_least32_t i = 38700;

or

int_fast32_t i = 38700;

are both guaranteed, but Paul Hsieh's original composition is not.
 
W

William Pursell

You want to do math in a ring, without knowing what ring you are in?

When dealing with signed types, there
is no ring in sight since overflow results
in UB.
 
F

Flash Gordon

CBFalconer wrote, On 19/01/08 02:32:
No, because the contents of stdint.h are optional, 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. However the types are all
aliases for something in the byte, short, int, long, long long (and
unsigned) group. 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

If that is your requirement use the int_least or int_fast types. These
are required to be provided for 8, 16, 32 and 64 bits. However, that is
not what Ian was talking about.
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.

Of you write a replacement for stdint.h for the implementations you care
about that do not have it.
 
R

Richard Heathfield

Philip Potter said:
I'm afraid even on a C99 compiler it's not guaranteed to work.

Oh, of course - support for intN_t is optional (subject to terms and
conditions). Thank you for the correction.
int_least32_t i = 38700;

or

int_fast32_t i = 38700;

are both guaranteed, but Paul Hsieh's original composition is not.

<nod>
 
M

Malcolm McLean

Ian Collins said:
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.
 
M

Malcolm McLean

Jack Klein said:
On Fri, 18 Jan 2008 11:29:48 +0000, Richard Heathfield

Note I am not accusing anyone in particular of being a "predominately
desktop/hosted environment programmer". It is a general observation,
not aimed at anyone in particular.
You get some reallly horrible people in the embedded world. Not
programmmers. Engineers, and people who manage engineers. It's just a
different, nineteenth century attitude to labour (cue for Nilges to take up
this thread).

I've found desktop programming to be more congenial, and the problems are
generally more interesting. In the embedded world you seem to spend most of
you time hooking up buttons to each other.
 
B

Bart C

CBFalconer said:
No, it isn't. It will fail miserably on a C90 system. Instead all
you need is a quick macro somewhere that will define MYTYPE as int
or long, depending on values in limits.h. This is system
independant, avoids oversized beasts, etc. etc. It doesn't need
sizes that are multiples of 8 either. How are you going to handle
a machine with a 9 bit byte, an 18 bit short, 36 bit int, 72 bit
long? Or other.

Those 18/36-bit systems are really thick on the ground. The only ones I'm
even aware of are long obsolete.

Computers with power-of-two bit sizes seem to be dominant, which must be why
the C99 standard appears to be littered with 8,16,32,64-bit references and
not 9,18,36,72-bit ones.

(The 36-bit machine I used at college was a splendid beast to work with
however. And the bytes were usually 7 bits: 7,18,36,72-bits, much more fun.)
 
M

Malcolm McLean

Ian Collins said:
My approach (shared by a number of opensource projects, libgd for
example) is to test for 64 bit types and use them at configuration or
build time if they are there.
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.
Note that to submit jobs to my supercomputer I have to put them into a
queue. So if I have to wait 3 hours to get a slot, only to find that an
index goes out of range, it's really irritating.
 
B

Bart C

For exact-width types, I actually lean toward considering ugliness a
Good Thing.

Most people who think they need exact-width types are wrong, and making
them as ugly and inconvenient as possible discourages their use (which
on the whole is a Good Thing);...

If you mix languages like C and something else, it sort of becomes important
to know what bit-widths C is using.

It becomes worse when mixing two implementations of C which cannot agree
what they mean by int or long int, on the same hardware.

Maybe CPU manufacturers like Intel should keep the word sizes of their
processors secret to encourage good portable programming.
 
C

CBFalconer

Ian said:
Because the *platform* will have the stdint.h types defined and any C
compiler on that platform will accept (either by implementing or
ignoring) the subset of C99 features the (POSIX) standard requires
(restrict for example).

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

Army1987

Paul said:
Floating point is a superset of integers. (Check your C lib
documentation for the modf() function if you don't believe me.) In
actual practice, I've found doubles as integers to actually be quite
useful to me (like knowing the exact number of seconds elapsed since
12:00AM 1 Jan 0 AD using the same type for knowing the exact number of
milliseconds since an application event).

There is no 0 AD. The year before 1 AD is called 1 BC by some people, and
0 (with no reference of any Lord or Christ) by other people. The year
before that is called 2 BC by the former people and -1 by the latter, and
so on.
 
C

CBFalconer

Ian said:
Does every word posted here have to be in the ISO C standard to meet
with your approval? Read what I was answering.

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.
 
A

Army1987

Paul said:
You are missing my point. Its not the 4 bits *above* 32 that are the
problem, its the 4 bits *BELOW* 40 that are the problem. If you feed
a 36 bit algorithm with a 40 bit value, then it might not function
correctly.
int isprime(unsigned long long int n)
{
if (n > 0xfffffffffULL) {
errno = ERANGE;
return -1;
} else {
/* ... */
if (/* n is prime */ ... ) return 1;
else return 0;
}
}
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

C99 integer types 24
Types 58
Types in C 117
Integer types in embedded systems 22
C99 stdint.h 20
Performance of signed vs unsigned types 84
ansi types 11
using pre-processor to count bits in integer types... 17

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top