longs, long longs, short short long ints . . . huh?!

Discussion in 'C Programming' started by David Geering, Jan 8, 2007.

  1. Is there any standard as to what a long and int mean or is it compiler
    dependent? Or furthermore architecture dependent?

    I know a short short long int isn't actually a recognised type, but if you
    wanted to make sure it was 16-bit, 32-bit or 64-bit etc, can you rely on
    these type names alone? If not, is there any way to ensure you get a
    64/32/16-bit int when you want one?

    Cheers,
    Dave.
     
    David Geering, Jan 8, 2007
    #1
    1. Advertising

  2. David Geering

    Guest

    David Geering wrote:
    > Is there any standard as to what a long and int mean or is it compiler
    > dependent? Or furthermore architecture dependent?


    It's compiler and architecture dependent. C only specifies the minimum
    size of a type, not it's actual implemented size. To comply with C, int
    needs to be at least 16 bits, long needs to be at least 32 bits and
    long long needs to be at least 64 bits. A compiler may decide to
    implement int == long == long long == 64 bits on any platform (It's
    common nowdays to see 32 bit ints on 8 bit platforms).

    > I know a short short long int isn't actually a recognised type, but if you
    > wanted to make sure it was 16-bit, 32-bit or 64-bit etc, can you rely on
    > these type names alone? If not, is there any way to ensure you get a
    > 64/32/16-bit int when you want one?


    I usually use one of 2 methods:

    If the data is not arithmetic and I'm only doing bitwise operations on
    it then I treat it as a byte array. This is not 100% portable since I
    make the assumption that a byte is exactly 8 bits (though this method
    does not really depend on the assumption, it's easier with the
    assumption).

    If the data is arithmetic then choose the largest size to properly
    represent the data and use masking to truncate the data.

    The real issue of wanting an exact bitlength of a datatype is when you
    want to communicate the data with an external program either via
    transmitting it or saving it to file. There are lots of threads
    discussing this issue but usually under the heading of endianness and
    portability. But the advice is still useful here. Read/write the data a
    byte at a time using shift operators. This allows you to discard/ignore
    the extra bits in the variable if it happens to have more bits than you
    intended.
     
    , Jan 8, 2007
    #2
    1. Advertising

  3. David Geering

    santosh Guest

    David Geering wrote:
    > Is there any standard as to what a long and int mean or is it compiler
    > dependent? Or furthermore architecture dependent?


    Their exact size and range are implementation specific. Apply the
    sizeof operator to get the size in bytes, (a byte is not necessarily an
    octet in C), and use the macros defined in limits.h and float.h to find
    out the range.

    The standard does specify certain minimum requirements that all
    conforming implementations must meet. See section 5.2.4.2 of the C99
    draft at the link below:
    <http://people.freebsd.org/~green/c9x-draft.txt>

    > I know a short short long int isn't actually a recognised type, but if you
    > wanted to make sure it was 16-bit, 32-bit or 64-bit etc, can you rely on
    > these type names alone? If not, is there any way to ensure you get a
    > 64/32/16-bit int when you want one?


    C99 has defined a bunch of new types for these purposes. They're
    defined in stdint.h and some associated format specifiers for doing I/O
    with them are in inttypes.h. For example if you need a type whose size
    is exactly 32 bits, use int32_t or uint32_t.

    Look up these standard header files on your system.

    Also look up section 7.18 and 7.8 of the draft linked above.
     
    santosh, Jan 8, 2007
    #3
  4. David Geering

    CBFalconer Guest

    santosh wrote:
    > David Geering wrote:
    >

    .... snip ...
    >
    >> I know a short short long int isn't actually a recognised type,
    >> but if you wanted to make sure it was 16-bit, 32-bit or 64-bit
    >> etc, can you rely on these type names alone? If not, is there
    >> any way to ensure you get a 64/32/16-bit int when you want one?

    >
    > C99 has defined a bunch of new types for these purposes. They're
    > defined in stdint.h and some associated format specifiers for
    > doing I/O with them are in inttypes.h. For example if you need a
    > type whose size is exactly 32 bits, use int32_t or uint32_t.
    >
    > Look up these standard header files on your system.


    And then avoid using them. They are not required, and the result
    is non-portable code.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Jan 8, 2007
    #4
  5. David Geering

    santosh Guest

    CBFalconer wrote:
    > santosh wrote:
    > > David Geering wrote:
    > >

    > ... snip ...
    > >
    > >> I know a short short long int isn't actually a recognised type,
    > >> but if you wanted to make sure it was 16-bit, 32-bit or 64-bit
    > >> etc, can you rely on these type names alone? If not, is there
    > >> any way to ensure you get a 64/32/16-bit int when you want one?

    > >
    > > C99 has defined a bunch of new types for these purposes. They're
    > > defined in stdint.h and some associated format specifiers for
    > > doing I/O with them are in inttypes.h. For example if you need a
    > > type whose size is exactly 32 bits, use int32_t or uint32_t.
    > >
    > > Look up these standard header files on your system.

    >
    > And then avoid using them. They are not required, and the result
    > is non-portable code.


    The OP did ask for types of specific width. He should be aware that
    they may not be defined for all implementations.
     
    santosh, Jan 8, 2007
    #5
  6. On Mon, 08 Jan 2007 00:43:42 -0800, wrote:
    >
    > If the data is arithmetic then choose the largest size to properly
    > represent the data and use masking to truncate the data.
    >


    Thanks all to the advice and comments. Usually I will be dealing with
    arithmetic operations so I will take your advice and truncate. It is all
    unsigned data as well so it would make it quite simple.

    Thanks again.
     
    David Geering, Jan 9, 2007
    #6
  7. David Geering

    Jack Klein Guest

    On Mon, 08 Jan 2007 06:15:54 -0500, CBFalconer <>
    wrote in comp.lang.c:

    > santosh wrote:
    > > David Geering wrote:
    > >

    > ... snip ...
    > >
    > >> I know a short short long int isn't actually a recognised type,
    > >> but if you wanted to make sure it was 16-bit, 32-bit or 64-bit
    > >> etc, can you rely on these type names alone? If not, is there
    > >> any way to ensure you get a 64/32/16-bit int when you want one?

    > >
    > > C99 has defined a bunch of new types for these purposes. They're
    > > defined in stdint.h and some associated format specifiers for
    > > doing I/O with them are in inttypes.h. For example if you need a
    > > type whose size is exactly 32 bits, use int32_t or uint32_t.
    > >
    > > Look up these standard header files on your system.

    >
    > And then avoid using them. They are not required, and the result
    > is non-portable code.


    They ARE required for any even slightly conforming C99 compiler, and
    are available with most current C90 versions as extensions.

    And it is quite easy to roll your own on virtually every
    implementation that supports the underlying types. With the exception
    of the 64-bit types, that includes all the compilers used by 98% or
    99% of all the working C programmers in the world.

    One of the reasons that C99 is so poorly supported is that C
    programmers who know about it advise others not to use its features
    because they are not widely supported. That's a vicious circle.

    If certain posters here spent as much time lobbying their compiler
    vendors/suppliers to implement the current C standard as they did
    advising others not to use it, perhaps the situation would change.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://c-faq.com/
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jan 9, 2007
    #7
  8. David Geering

    Ian Collins Guest

    Jack Klein wrote:
    >
    > One of the reasons that C99 is so poorly supported is that C
    > programmers who know about it advise others not to use its features
    > because they are not widely supported. That's a vicious circle.
    >
    > If certain posters here spent as much time lobbying their compiler
    > vendors/suppliers to implement the current C standard as they did
    > advising others not to use it, perhaps the situation would change.
    >

    Well said!

    --
    Ian Collins.
     
    Ian Collins, Jan 9, 2007
    #8
  9. David Geering

    CBFalconer Guest

    Jack Klein wrote:
    > CBFalconer <> wrote in comp.lang.c:
    >> santosh wrote:
    >>> David Geering wrote:
    >>>

    >> ... snip ...
    >>>
    >>>> I know a short short long int isn't actually a recognised type,
    >>>> but if you wanted to make sure it was 16-bit, 32-bit or 64-bit
    >>>> etc, can you rely on these type names alone? If not, is there
    >>>> any way to ensure you get a 64/32/16-bit int when you want one?
    >>>
    >>> C99 has defined a bunch of new types for these purposes. They're
    >>> defined in stdint.h and some associated format specifiers for
    >>> doing I/O with them are in inttypes.h. For example if you need a
    >>> type whose size is exactly 32 bits, use int32_t or uint32_t.
    >>>
    >>> Look up these standard header files on your system.

    >>
    >> And then avoid using them. They are not required, and the result
    >> is non-portable code.

    >
    > They ARE required for any even slightly conforming C99 compiler, and
    > are available with most current C90 versions as extensions.
    >
    > And it is quite easy to roll your own on virtually every
    > implementation that supports the underlying types. With the exception
    > of the 64-bit types, that includes all the compilers used by 98% or
    > 99% of all the working C programmers in the world.
    >
    > One of the reasons that C99 is so poorly supported is that C
    > programmers who know about it advise others not to use its features
    > because they are not widely supported. That's a vicious circle.


    I'm not doing that. The point is that those definitions may not be
    available on the destination, regardless of the standard in
    effect. In general they are unnecessary in non-system code. The
    only real use, to me, is to force compilation errors when the
    implementation is unsuitable.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
     
    CBFalconer, Jan 9, 2007
    #9
  10. Jack Klein <> writes:
    > On Mon, 08 Jan 2007 06:15:54 -0500, CBFalconer <>
    > wrote in comp.lang.c:
    >> santosh wrote:
    >> > David Geering wrote:
    >> >

    >> ... snip ...
    >> >
    >> >> I know a short short long int isn't actually a recognised type,
    >> >> but if you wanted to make sure it was 16-bit, 32-bit or 64-bit
    >> >> etc, can you rely on these type names alone? If not, is there
    >> >> any way to ensure you get a 64/32/16-bit int when you want one?
    >> >
    >> > C99 has defined a bunch of new types for these purposes. They're
    >> > defined in stdint.h and some associated format specifiers for
    >> > doing I/O with them are in inttypes.h. For example if you need a
    >> > type whose size is exactly 32 bits, use int32_t or uint32_t.
    >> >
    >> > Look up these standard header files on your system.

    >>
    >> And then avoid using them. They are not required, and the result
    >> is non-portable code.

    >
    > They ARE required for any even slightly conforming C99 compiler, and
    > are available with most current C90 versions as extensions.


    I agree with your overall argument, but you missed the specific point
    about the exact-width types.

    The <stdint.h> header is required. The exact-width types are not.
    For example, a implementation will not provide int32_t *unless* it
    happens to have a signed integer type with width 32, no padding bits,
    and a two's complement representation. (And yes, I've used a system
    that had no such type -- though it didn't have a C99 compiler either.)

    > And it is quite easy to roll your own on virtually every
    > implementation that supports the underlying types. With the exception
    > of the 64-bit types, that includes all the compilers used by 98% or
    > 99% of all the working C programmers in the world.


    I agree that providing your own <stdint.h> for implementations that
    don't have it is fairly straightforward. See, for example, Doug
    Gwyn's public-domain q8 at <http://www.lysator.liu.se/c/q8/index.html>.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jan 9, 2007
    #10
  11. Jack Klein said:

    <snip>

    > If certain posters here spent as much time lobbying their compiler
    > vendors/suppliers to implement the current C standard as they did
    > advising others not to use it, perhaps the situation would change.


    But "certain posters here" (amongst whose number I unhesitatingly include
    myself) are interested not in change for the sake of change, but in writing
    portable C programs. This is already possible in C90, so why bother
    lobbying? Those who need portability can ignore C99. Those who desire its
    features can embrace them if they are prepared to pay the portability cost.

    The only ones who need to lobby implementors are those who desire C99's
    features *and* portability. For such people, lobbying one implementor is
    insufficient. They need to lobby *all* the implementors whose
    implementations they use and which do not yet conform to C99.

    Good luck with that, but I'm not holding my breath.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Jan 9, 2007
    #11
  12. David Geering

    Spoon Guest

    David Geering wrote:

    > Is there any standard as to what a long and int mean or is it compiler
    > dependent? Or furthermore architecture dependent?
    >
    > I know a short short long int isn't actually a recognised type, but if you
    > wanted to make sure it was 16-bit, 32-bit or 64-bit etc, can you rely on
    > these type names alone? If not, is there any way to ensure you get a
    > 64/32/16-bit int when you want one?


    POSIX defines the stdint.h header.
    http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html

    Note: my answer is off-topic for comp.lang.c
    cf. comp.unix.programmer to discuss POSIX.
     
    Spoon, Jan 9, 2007
    #12
  13. Spoon <> writes:
    > David Geering wrote:
    >> Is there any standard as to what a long and int mean or is it compiler
    >> dependent? Or furthermore architecture dependent?
    >> I know a short short long int isn't actually a recognised type, but
    >> if you
    >> wanted to make sure it was 16-bit, 32-bit or 64-bit etc, can you rely on
    >> these type names alone? If not, is there any way to ensure you get a
    >> 64/32/16-bit int when you want one?

    >
    > POSIX defines the stdint.h header.
    > http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html
    >
    > Note: my answer is off-topic for comp.lang.c
    > cf. comp.unix.programmer to discuss POSIX.


    Sorry, I'm afraid it's actually topical. stdint.h is defined by the
    C99 standard. See the change history section at the bottom of the web
    page.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jan 9, 2007
    #13
  14. "David Geering" <> wrote in message
    > On Mon, 08 Jan 2007 00:43:42 -0800, wrote:
    >>
    >> If the data is arithmetic then choose the largest size to properly
    >> represent the data and use masking to truncate the data.
    >>

    >
    > Thanks all to the advice and comments. Usually I will be dealing with
    > arithmetic operations so I will take your advice and truncate. It is all
    > unsigned data as well so it would make it quite simple.
    >

    It's not often that you need a number modulus a power of two power of two.
    It's even rarer that using the free modulus due to overflow makes an
    appreciable difference to program run time.

    Join my campaign for 64 bit ints and just store everything in ints and have
    done.
     
    Malcolm McLean, Jan 9, 2007
    #14
  15. David Geering

    Richard Bos Guest

    CBFalconer <> wrote:

    > santosh wrote:
    > > David Geering wrote:
    > >
    > >> I know a short short long int isn't actually a recognised type,
    > >> but if you wanted to make sure it was 16-bit, 32-bit or 64-bit
    > >> etc, can you rely on these type names alone? If not, is there
    > >> any way to ensure you get a 64/32/16-bit int when you want one?

    > >
    > > C99 has defined a bunch of new types for these purposes. They're
    > > defined in stdint.h and some associated format specifiers for
    > > doing I/O with them are in inttypes.h. For example if you need a
    > > type whose size is exactly 32 bits, use int32_t or uint32_t.
    > >
    > > Look up these standard header files on your system.

    >
    > And then avoid using them. They are not required, and the result
    > is non-portable code.


    Depends on what you want, and what you use. _If_ you have C99, or a
    hand-hacked header for C89, which is simple enough to make, then:

    - the header _must_ supply int_least8_t, int_least16_t, int_least32_t
    and int_least64_t, so if what you want is a type that's guaranteed to
    have at least that many bits, and by preference no more than necessary,
    you can use these;
    - if you really need _exactly_ 16, 32, and 64-bit types, you can safely
    use int32_t et. al., since if a C99 implementation doesn't have these,
    it doesn't have any other type you can use, either. This is because _if_
    the implementation supplies any integer of exactly 8, 16, 32 or 64 bits,
    it _must_ also supply the corresponding intN_t.

    Richard
     
    Richard Bos, Jan 11, 2007
    #15
  16. (Richard Bos) writes:
    [...]
    > - if you really need _exactly_ 16, 32, and 64-bit types, you can safely
    > use int32_t et. al., since if a C99 implementation doesn't have these,
    > it doesn't have any other type you can use, either. This is because _if_
    > the implementation supplies any integer of exactly 8, 16, 32 or 64 bits,
    > it _must_ also supply the corresponding intN_t.


    Assuming that the type has a two's complement representation and no
    padding bits.

    Even if the implementation doesn't provide int32_t, you can have a
    type that's exactly 32 bits as long as 32 % CHAR_BIT == 0:
    unsigned char[32/CHAR_BIT]
    To perform arithmetic operations, you can copy the value to an object
    of type long or unsigned long (which is guaranteed to be big enough).
    This could be useful if you need to use some externally imposed data
    format.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jan 11, 2007
    #16
    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. Replies:
    3
    Views:
    580
    Mark P
    Apr 3, 2005
  2. Chris N. Hinds

    unions with long long ints and doubles?

    Chris N. Hinds, Sep 30, 2003, in forum: C Programming
    Replies:
    3
    Views:
    425
    Barry Schwarz
    Oct 2, 2003
  3. Skybuck Flying

    ints ints ints and ints

    Skybuck Flying, Jul 8, 2004, in forum: C Programming
    Replies:
    24
    Views:
    852
    Jack Klein
    Jul 10, 2004
  4. Ray Dillinger

    format specifier for long long ints....

    Ray Dillinger, Mar 26, 2006, in forum: C Programming
    Replies:
    4
    Views:
    496
    Keith Thompson
    Mar 27, 2006
  5. fermineutron

    C / asm / long ints

    fermineutron, Oct 26, 2006, in forum: C Programming
    Replies:
    32
    Views:
    1,151
    =?utf-8?B?SGFyYWxkIHZhbiBExLNr?=
    Nov 11, 2006
Loading...

Share This Page