must size_t be an alias?

[Old Wolf]

Does size_t have to be the same as another integral type?

For example, could we have a system with 36-bit size_t, and no other
integral types exceeding 32 bits?

 

[Eric Sosman]

Does size_t have to be the same as another integral type?

In C90, it must be one of unsigned char, short, int, or
long. In C99, it can be any of those, or unsigned long long,
or another implementation-defined unsigned integral type. The
Standard says it "should" be wider than unsigned long only if
the implementation actually supports object sizes that would
require it, but "should" is suggestive and not prescriptive.

For example, could we have a system with 36-bit size_t, and no other
integral types exceeding 32 bits?

In C90, no: size_t must be one of the "ordinary" types,
so that type (and perhaps others) must also be 36 bits wide
and hence wider than 32 bits. In C99, no: unsigned long long
must be at least 64 bits wide, hence wider than a 36-bit
size_t.

But that's not quite the question you meant to ask, I think.
The "exceeding" changes the meaning a little; what you're after
is whether size_t can have a width that is not the same as any
other integral type. In C90, no: size_t *is* a synonym for one
of the ordinary types. In C99, I think the answer is yes: one
could have an implementation with 9-bit unsigned char, 18-bit
ushort, 27-bit uint, 36-bit size_t, 45-bit ulong, and 72-bit
ullong. (It's widely understood that ptrdiff_t is the same
width as size_t, but I can't find language that requires this.
Also, there might be <stdint.h> types that are 36 bits wide,
but I don't think they're required to be present.)

 

[Ben Pfaff]

It's widely understood that ptrdiff_t is the same width as
size_t, but I can't find language that requires this.

The limits in C99 7.18.3 imply that on a 16-bit int system,
size_t can be "unsigned int" but ptrdiff_t must be "long int" or
wider:

- limits of ptrdiff_t
PTRDIFF_MIN -65535
PTRDIFF_MAX +65535
....
- limit of size_t
SIZE_MAX 65535

 

[Skarmander]

In C90, it must be one of unsigned char, short, int, or
long. In C99, it can be any of those, or unsigned long long,
or another implementation-defined unsigned integral type. The
Standard says it "should" be wider than unsigned long only if
the implementation actually supports object sizes that would
require it, but "should" is suggestive and not prescriptive.


In C90, no: size_t must be one of the "ordinary" types,
so that type (and perhaps others) must also be 36 bits wide
and hence wider than 32 bits. In C99, no: unsigned long long
must be at least 64 bits wide, hence wider than a 36-bit
size_t.

But that's not quite the question you meant to ask, I think.
The "exceeding" changes the meaning a little; what you're after
is whether size_t can have a width that is not the same as any
other integral type. In C90, no: size_t *is* a synonym for one
of the ordinary types. In C99, I think the answer is yes: one
could have an implementation with 9-bit unsigned char, 18-bit
ushort, 27-bit uint, 36-bit size_t, 45-bit ulong, and 72-bit
ullong.

Are you still using the Mark I DS9K? I thought they stopped supporting
those. The Mark II has much less intuitive sizes, and more padding bits. You
can never have too much of those, after all.

S.

 

[Guest]

Are you still using the Mark I DS9K? I thought they stopped supporting
those. The Mark II has much less intuitive sizes, and more padding bits. You
can never have too much of those, after all.

Huh. Here's a thought: let's say sizeof(int) == 65536, but only 65535
bytes are allowed in an object. Let's also say a certain implementation
rejects any program declaring main() as returning int because of this.
Could such an implementation be conforming? I'm not asking if it could
be /useful/, just conforming. (5.2.4.1's "one program" that must be
translatable and executable need not be strictly conforming, so it can
declare main() as returning void or char.) And if it is a conforming
implementation, regardless of whether it was intended to be allowed,
does any strictly conforming program (which by definition can't exceed
any minimum implementation limit) exist?

 

[Skarmander]

Huh. Here's a thought: let's say sizeof(int) == 65536,
Gack.

but only 65535 bytes are allowed in an object. Let's also say a certain
implementation rejects any program declaring main() as returning int
because of this. Could such an implementation be conforming? I'm not
asking if it could be /useful/,

Good, because we all know the answer to that.

just conforming. (5.2.4.1's "one program" that must be translatable and
executable need not be strictly conforming, so it can declare main() as
returning void or char.) And if it is a conforming implementation,
regardless of whether it was intended to be allowed, does any strictly
conforming program (which by definition can't exceed any minimum
implementation limit) exist?

As far as I can tell, it's allowed, and no strictly conforming programs
exist for such an implementation.

Keep in mind that 5.2.4.1 actually says nothing about which programs will be
rejected, only that at least one program with particular constructs must be
accepted. Formally speaking this is a very weak constraint on the
implementation, so your hypothetical perverse implementation isn't even that
shocking. Implementations have a lot of leeway when it comes to
implementation-defined limits.

The standard doesn't even say that the minimal maximum object size must be
65535 bytes. It only says that at least one program containing at least one
instance of each of the limits in 5.2.4.1 must be translatable and
executable. A hosted[*] implementation would formally be allowed to accept
an object of 65535 bytes only for that program and impose a maximum object
size of 1 byte everywhere else (rejecting every other would-be conforming
program if sizeof(int) > 1), although it would be deliberately perverse and
going directly against the intent of the standard.

Truly, only the DS9K manufacturers would devise such devious torture, and
even *they* would catch *some* flak for doing so. I'd expect most
programmers to simply take their ball and go home.

S.
[*]It is conceivable for a conforming freestanding implementation to have
exactly the restriction mentioned (with sizeof(FOO) == 1), which would
basically mean you cannot declare nontrivial arrays and structs (at least
not instances of them) and you cannot use string literals at all. Memory has
to be extremely limited for these restrictions to make any sense.