size_t

[Ioannis Vranos]

Is it possible the following condition to be true under C95?

sizeof(size_t)> sizeof(unsigned long)

 

[Walter Roberson]

Is it possible the following condition to be true under C95?

sizeof(size_t)> sizeof(unsigned long)

size_t is not required to be one of the standard integral
types, just "an unsigned integral type".

 

[Harald van Dijk]

I'll assume you meant to ask about size_t's width rather than its size.
You can express this as

(size_t) -1 > (unsigned long) -1

size_t is not required to be one of the standard integral types, just
"an unsigned integral type".

Before C99, the definition of "an unsigned integral type" did not allow
for any non-standard integral types, so size_t was not allowed to be wider
than unsigned long.

 

[CBFalconer]

Is it possible the following condition to be true under C95?

sizeof(size_t)> sizeof(unsigned long)

I believe no, because size_t is specified to be an integer type,
and the only C95 integer types are char, short, int, long, with
possible un/signed attributes.

 

[Keith Thompson]

I believe no, because size_t is specified to be an integer type,
and the only C95 integer types are char, short, int, long, with
possible un/signed attributes.

As Walter Roberson alluded to, it's possible that size_t is a typedef
for unsigned int, and that sizeof(unsigned int) > sizeof(unsigned long).

It's very unlikely. In C99 terms, unsigned int would have to have
padding bits. If unsigned int and unsigned long have the same range,
unsigned int would have to have more padding bits than unsigned long.
If the range of unsigned int is narrower than the range of unsigned
long, then unsigned int would have to have a *lot* of padding bits.
(I don't believe C95 defines the concept of "padding bits", but its
description of the representation of integer types is loose enough to
allow for them.)

I'd be very surprised if such an implementation has ever existed.

It's true that, in C95, size_t must be a typedef for one of unsigned
char, unsigned short, unsigned int, or unsigned long. (Whether it can
be a typedef for plain char if plain char is unsigned is not a
sufficiently interesting question for me to spend time figuring out
the answer.) In practice, it will (almost?) always be either unsigned
int or unsigned long, more likely the latter.

Even now the standard suggests not making size_t any wider than
unsigned long. n1256 7.17 says:

Recommended practice

The types used for size_t and ptrdiff_t should not have an integer
conversion rank greater than that of signed long int unless the
implementation supports objects large enough to make this
necessary.

The original C99 standard doesn't have this wording; it was added in
one of the Technical Corrigenda.

So the quick answer to Ioannis's actual question is no, size_t can't
be wider than unsigned long in C95.

But be careful. Though few implementations fully support C99, many
support parts of it; "long long", for example, is quite common. I
don't know of any implementations where size_t is wider than unsigned
long, but it's a possibility, and you shouldn't assume that size_t
can't be wider than unsigned long if you want your code to be
future-proof.

On the other other hand, something like this:

printf("sizeof obj = %lu\n", (unsigned long)sizeof obj);

can fail only if size_t is wider than unsigned long *and* the size of
obj actually exceeds ULONG_MAX. And even then, the printed result
wraps around; there's no undefined behavior.