Actual type of intmax_t and uintmax_t

[santosh]

Hello all,

In section 7.18.1.5 the Standard says that intmax_t and uintmax_t
designate signed and unsigned integer types capable of representing any
value of any signed or unsigned integer type, respectively.

Is this restricted to Standard types like long long and unsigned long
long or must intmax_t and uintmax_t take into account any extended
width types provided by the implementation? For example if an
implementation provides a 128 bit integer type, should intmax_t and
uintmax_t be typedefs for this type?

The wording "capable of representing any value of any (un)signed integer
type" is ambiguous.

Thanks.

 

[Harald van Dijk]

Hello all,

In section 7.18.1.5 the Standard says that intmax_t and uintmax_t
designate signed and unsigned integer types capable of representing any
value of any signed or unsigned integer type, respectively.

Is this restricted to Standard types like long long and unsigned long
long or must intmax_t and uintmax_t take into account any extended width
types provided by the implementation?

It must take into account any type which either the standard or the
implementation documents as an integer type. The DS9000 is allowed to
provide an 128-bit type which behaves exactly like integer types, but
isn't referred to as an integer type in the documentation. If it does,
then uintmax_t can't be that specific type, but equally, it's not allowed
to use that type for uint128_t.

For example if an implementation
provides a 128 bit integer type, should intmax_t and uintmax_t be
typedefs for this type?

Assuming no larger integer type exists, then yes.

The wording "capable of representing any value of any (un)signed integer
type" is ambiguous.

Thanks.

In C90, an integer type was always a standard integer type, but C99
changed the definition of "signed integer types" (6.2.5p4) and "unsigned
integer types" (6.2.5p5) to include extended integer types.

 

[vippstar]

The wording "capable of representing any value of any (un)signed integer
type" is ambiguous.

That means UINTMAX_MAX is guaranteed to be equal or bigger than any
other unsigned integral _MAX type.

 

[santosh]

It must take into account any type which either the standard or the
implementation documents as an integer type.

So I guess under lcc-win32, (not bashing jacob, merely taking it as an
example), intmax_t and uintmax_t should be aliases to his 1024 bit
bignum integer type?

So that means that if you use these types you might unwittingly use a
compiler specific extensions even under strictly conforming mode...?

<thanks for rest of the information>

 

[vippstar]

So I guess under lcc-win32, (not bashing jacob, merely taking it as an
example), intmax_t and uintmax_t should be aliases to his 1024 bit
bignum integer type?

No because his bignum integer type is not a type defined by the
standard.

 

[Harald van Dijk]

So I guess under lcc-win32, (not bashing jacob, merely taking it as an
example), intmax_t and uintmax_t should be aliases to his 1024 bit
bignum integer type?

Assuming it behaves as an integer type and is documented as such, yes.
There are some bignum implementations that don't behave like integer
types, and I don't know how jacob's is implemented.

So that means that if you use these types you might unwittingly use a
compiler specific extensions even under strictly conforming mode...?

Yes, you can write strictly conforming code, which the compiler is
allowed to implement using compiler-specific extensions. This is the case
in C in many situations. The standard headers often contain compiler-
specific macro definitions, and if I take something as simple as abs(-1),
it might macro-expand on a conforming implementation to __builtin_abs(-1).

 

[James Kuyper]

No because his bignum integer type is not a type defined by the
standard.

No, as explained above, intmax_t and uintmax_t don't have to be types
defined by the standard. They can also be extended integer types. That
means that they have to obey all of the rules laid down by the standard
for integer types, but can have a name that isn't defined by the
standard. I think it's unlikely that a bignum type could be implemented
in a way that fits all of those rules, but if it does, it can and should
be used as intmax_t or uintmax_t.

 

[Ben Pfaff]

The DS9000 is allowed to provide an 128-bit type which behaves
exactly like integer types, but isn't referred to as an integer
type in the documentation.

I don't think that a type that is not an integer type could
participate in behavior that is restricted to integer types. For
example, only integer types have integer conversion rank, so I
would argue that only integer types can participate in arithmetic
conversions for integer operands.

 

[Harald van Dijk]

I don't think that a type that is not an integer type could participate
in behavior that is restricted to integer types. For example, only
integer types have integer conversion rank, so I would argue that only
integer types can participate in arithmetic conversions for integer
operands.

The behaviour will likely already be outside the scope of the C standard
by merely declaring an object of this extended non-integer type (it can't
be one of the (u)int*_t types), but if there is a way to use them that
doesn't involve either constraint violations or undefined behaviour, then
I agree.

 

[Keith Thompson]

So I guess under lcc-win32, (not bashing jacob, merely taking it as an
example), intmax_t and uintmax_t should be aliases to his 1024 bit
bignum integer type?

If and only iff his bignum integer type is, and is documented as, an
"extended integer type" as defined by the standard.

So that means that if you use these types you might unwittingly use a
compiler specific extensions even under strictly conforming mode...?

I'm not sure that extended integer types are considered "extensions";
they're optional features.

Note that an implementation could legally make long long 1024 bits,
and make intmax_t a typedef for long long. This might involve a great
deal of runtime overhead, but it's all part of the core language, not
an extension. Doing the same thing with an extended integer type
rather than with long long doesn't really change anything.