Re: Standard integer types vs <stdint.h> types

Malcolm McLean wrote, On 18/01/08 09:09:
<euler70@xxxxxxxxx> wrote in message
char and unsigned char have specific purposes: char is useful for
representing characters of the basic execution character set and
unsigned char is useful for representing the values of individual
bytes.

Yes. Also pointer to char is the type normally taken by "string" functions including (but not limited to) those in the standard library.

The remainder of the standard integer types are general
purpose. Their only requirement is to satisfy a minimum range of
values, and also int "has the natural size suggested by the
architecture of the execution environment".

Yes.

What are the reasons for
using these types instead of the [u]int_fastN_t types of <stdint.h>?

Well, stdint.h was only introduced in the 1999 standard, a standard that is not fully implemented by many compilers and not at all by at least one major player.

If I want just a signed integer with at least 16 width, then why
choose int instead of int_fast16_t? int_fast16_t is the "fastest"
signed integer type that has at least 16 width, while int is simply a
signed integer type that has at least 16 width. It seems that choosing
int_fast16_t is at least as good as choosing int. This argument can be
made for N=8,16,32,64, and for the corresponding unsigned types.

Yes, this is true, and an excellent reason for using them. It does limit portability to implementations that do not support this part of C99, however it is always possible to write your own version of stdint.h for those systems.

<stdint.h> also offers [u]int_leastN_t types, which are useful when
keeping a small storage size is the greatest concern.

Yes. Also due to the possibly smaller size they can be *faster* for some purposes. For example if the smaller size means everything is kept in cache instead of having to be fetched.

The only benefit of using the standard integer types I can see is that
their ranges may expand as the C standard progresses, so code that
uses them might stay useful over time.

Yes, that is a potential advantage.

For example fseek of <stdio.h>
uses a long for its offset parameter, so if the range of long grows
then fseek will automatically offer a wider range of offsets.

There is an argument that fseek should have used another type...

Of course, that is why there is fsetpos.

It's also interesting to note (or maybe not) that in the Windows
world, the idea of long being general purpose has somewhat been
destroyed and long has become a type that must have exactly 32 bits.

Yes, and it is not entirely the fault of MS. It is the programmers who assumed that it would always be exactly 32 bits and/or assumed it would always be the same size as int. Not breaking such 3rd party code, as I understand it, was the reason for MS keeping long as 32 bits on Win64.

Yes, we're rapidly going down the path of destroying the C basic integer types.

Note that this is an opinion that seems to be almost unique to Malcolm. A lot of what Malcolm disagrees with was part of the original standard published in 1989 so he has a very strange idea of "rapidly".

Note that some others think the fixed width types are a mistake, although some of us disagree, there being arguments on both side. More people (I think) would have liked things like int32_t being the fast types and having int_exact or int_fixed for the optional fixed sized types.

Once you start inventing types like int_fast16_t people will use them, and the language becomes more and more difficult to read.

In *your* opinion.

My own view is that you should be able to stick to char for characters and int for integers, in almost every situation. However this is only tenable if you can use int as both an arbitrary array index and a fast type.

Which is not its purpose and does not agree with the way modern processors work since often a 32 bit integer will be faster than a 64 bit integer (even on 64 bit hardware) yet you need a 64 bit integer for an arbitrary index. Similar things were true for eariler HW in terms of 16/32 bits. So Malcolm's view is that C has to meet two contradictory requirements at the same time.
--
Flash Gordon
.

Relevant Pages