Actual type of intmax_t and uintmax_t

Discussion in 'C Programming' started by santosh, Dec 1, 2007.

  1. santosh

    santosh Guest

    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.
    santosh, Dec 1, 2007
    #1
    1. Advertising

  2. On Sat, 01 Dec 2007 19:04:53 +0530, santosh wrote:
    > 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.
    Harald van Dijk, Dec 1, 2007
    #2
    1. Advertising

  3. santosh

    Guest

    On Dec 1, 3:34 pm, santosh <> wrote:
    > 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.
    , Dec 1, 2007
    #3
  4. santosh

    santosh Guest

    Harald van D?k wrote:

    > On Sat, 01 Dec 2007 19:04:53 +0530, santosh wrote:
    >> 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.


    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>
    santosh, Dec 1, 2007
    #4
  5. santosh

    Guest

    On Dec 1, 4:41 pm, santosh <> wrote:
    > Harald van D?k wrote:
    > > On Sat, 01 Dec 2007 19:04:53 +0530, santosh wrote:
    > >> 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.

    >
    > 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.
    , Dec 1, 2007
    #5
  6. On Sat, 01 Dec 2007 20:11:00 +0530, santosh wrote:
    > Harald van D?k wrote:
    >> On Sat, 01 Dec 2007 19:04:53 +0530, santosh wrote:
    >>> 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.

    >
    > 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).
    Harald van Dijk, Dec 1, 2007
    #6
  7. santosh

    James Kuyper Guest

    wrote:
    > On Dec 1, 4:41 pm, santosh <> wrote:
    >> Harald van D?k wrote:
    >>> On Sat, 01 Dec 2007 19:04:53 +0530, santosh wrote:
    >>>> 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.

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


    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.
    James Kuyper, Dec 1, 2007
    #7
  8. santosh

    Ben Pfaff Guest

    Harald van Dijk <> writes:

    > 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.
    --
    char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
    ={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
    =b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
    2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
    Ben Pfaff, Dec 1, 2007
    #8
  9. On Sat, 01 Dec 2007 10:56:04 -0800, Ben Pfaff wrote:
    > Harald van Dijk <> writes:
    >> 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.


    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.
    Harald van Dijk, Dec 1, 2007
    #9
  10. santosh <> writes:
    > Harald van D?k wrote:
    >> On Sat, 01 Dec 2007 19:04:53 +0530, santosh wrote:
    >>> 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.

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

    --
    Keith Thompson (The_Other_Keith) <>
    Looking for software development work in the San Diego area.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Dec 1, 2007
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Buster Copley

    Re: Actual type of typedef?

    Buster Copley, Aug 5, 2003, in forum: C++
    Replies:
    1
    Views:
    316
    Kevin Goodsell
    Aug 5, 2003
  2. Replies:
    6
    Views:
    315
    Piotr Kobzda
    Jul 26, 2007
  3. Replies:
    4
    Views:
    379
    Daniel Pitts
    Oct 1, 2007
  4. Todd
    Replies:
    1
    Views:
    429
    Stefan Ram
    Aug 15, 2008
  5. mreister
    Replies:
    1
    Views:
    3,112
    mreister
    May 25, 2010
Loading...

Share This Page