Best Multi-Platform Way to Define Standard Types Such as UINT32

Discussion in 'C Programming' started by David T. Ashley, Jan 27, 2007.

  1. I'm writing code which will compile on multiple Windows and multiple *nix
    platforms. Some will have 64-bit integers, I believe.

    What is my best option to define platform-independent types such as UINT32
    or UINT64? I'm not sure how to sort out the various platforms and integer
    sizes, and some of it may even vary based on compiler options.

    Thanks
    --
    David T. Ashley ()
    http://www.e3ft.com (Consulting Home Page)
    http://www.dtashley.com (Personal Home Page)
    http://gpl.e3ft.com (GPL Publications and Projects)
    David T. Ashley, Jan 27, 2007
    #1
    1. Advertising

  2. David T. Ashley

    Ian Collins Guest

    David T. Ashley wrote:
    > I'm writing code which will compile on multiple Windows and multiple *nix
    > platforms. Some will have 64-bit integers, I believe.
    >
    > What is my best option to define platform-independent types such as UINT32
    > or UINT64? I'm not sure how to sort out the various platforms and integer
    > sizes, and some of it may even vary based on compiler options.
    >

    Probably a good place to start would be <stdint.h> on one of the 64 bit
    capable systems. I think you should use the standard types, rather than
    redefining them in caps.

    --
    Ian Collins.
    Ian Collins, Jan 27, 2007
    #2
    1. Advertising

  3. "Ian Collins" <> wrote in message
    news:...
    > David T. Ashley wrote:
    >> I'm writing code which will compile on multiple Windows and multiple *nix
    >> platforms. Some will have 64-bit integers, I believe.
    >>
    >> What is my best option to define platform-independent types such as
    >> UINT32
    >> or UINT64? I'm not sure how to sort out the various platforms and
    >> integer
    >> sizes, and some of it may even vary based on compiler options.
    >>

    > Probably a good place to start would be <stdint.h> on one of the 64 bit
    > capable systems. I think you should use the standard types, rather than
    > redefining them in caps.


    Thanks for that info. I looked up this file (<stdint.h>) on my Linux box,
    and it is just what I was looking for.

    However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
    the include directory, so just to be sure I wasn't missing something, I
    searched Microsoft's site by "stdint.h" and got no matches.

    I think the Microsoft tool chain doesn't have such a file. It isn't clear
    what to do, because even Windows will run on some 64-bit platforms.

    Suggestions?

    Dave.
    --
    David T. Ashley ()
    http://www.e3ft.com (Consulting Home Page)
    http://www.dtashley.com (Personal Home Page)
    http://gpl.e3ft.com (GPL Publications and Projects)
    David T. Ashley, Jan 27, 2007
    #3
  4. David T. Ashley

    jacob navia Guest

    David T. Ashley a écrit :
    > "Ian Collins" <> wrote in message
    > news:...
    >
    >>David T. Ashley wrote:
    >>
    >>>I'm writing code which will compile on multiple Windows and multiple *nix
    >>>platforms. Some will have 64-bit integers, I believe.
    >>>
    >>>What is my best option to define platform-independent types such as
    >>>UINT32
    >>>or UINT64? I'm not sure how to sort out the various platforms and
    >>>integer
    >>>sizes, and some of it may even vary based on compiler options.
    >>>

    >>
    >>Probably a good place to start would be <stdint.h> on one of the 64 bit
    >>capable systems. I think you should use the standard types, rather than
    >>redefining them in caps.

    >
    >
    > Thanks for that info. I looked up this file (<stdint.h>) on my Linux box,
    > and it is just what I was looking for.
    >
    > However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
    > the include directory, so just to be sure I wasn't missing something, I
    > searched Microsoft's site by "stdint.h" and got no matches.
    >
    > I think the Microsoft tool chain doesn't have such a file. It isn't clear
    > what to do, because even Windows will run on some 64-bit platforms.
    >
    > Suggestions?
    >
    > Dave.


    Yes. Just copy your linux stdint.h to your Microsoft installation...

    NOT very difficult. stdint.h is standard C. Microsoft dpesn't always
    comply with it but this is easy to follow.

    Of course you should remember that in 64 bit microsoft environment,
    long is 32 bits and under 64 bit linux it is 64 bits. The file would
    need at most a small editing change.
    jacob navia, Jan 27, 2007
    #4
  5. David T. Ashley

    Nelu Guest

    David T. Ashley <> wrote:
    > I'm writing code which will compile on multiple Windows and multiple *nix
    > platforms. Some will have 64-bit integers, I believe.


    There are standard types defined in stdint.h, although the header is
    available only in C99: uint32/64_t and uint_least32/64_t


    --
    Ioan - Ciprian Tandau
    tandau _at_ freeshell _dot_ org (hope it's not too late)
    (... and that it still works...)
    Nelu, Jan 27, 2007
    #5
  6. David T. Ashley

    Ian Collins Guest

    jacob navia wrote:
    > David T. Ashley a écrit :
    >
    >> "Ian Collins" <> wrote in message
    >> news:...
    >>
    >>> David T. Ashley wrote:
    >>>
    >>>> I'm writing code which will compile on multiple Windows and multiple
    >>>> *nix
    >>>> platforms. Some will have 64-bit integers, I believe.
    >>>>
    >>>> What is my best option to define platform-independent types such as
    >>>> UINT32
    >>>> or UINT64? I'm not sure how to sort out the various platforms and
    >>>> integer
    >>>> sizes, and some of it may even vary based on compiler options.
    >>>>
    >>>
    >>> Probably a good place to start would be <stdint.h> on one of the 64 bit
    >>> capable systems. I think you should use the standard types, rather than
    >>> redefining them in caps.

    >>
    >> Thanks for that info. I looked up this file (<stdint.h>) on my Linux
    >> box, and it is just what I was looking for.
    >>
    >> However, I also have Microsoft Visual C++. I couldn't find <stdint.h>
    >> in the include directory, so just to be sure I wasn't missing
    >> something, I searched Microsoft's site by "stdint.h" and got no matches.
    >>
    >> I think the Microsoft tool chain doesn't have such a file. It isn't
    >> clear what to do, because even Windows will run on some 64-bit platforms.
    >>

    > Yes. Just copy your linux stdint.h to your Microsoft installation...
    >
    > NOT very difficult. stdint.h is standard C. Microsoft dpesn't always
    > comply with it but this is easy to follow.
    >
    > Of course you should remember that in 64 bit microsoft environment,
    > long is 32 bits and under 64 bit linux it is 64 bits. The file would
    > need at most a small editing change.


    Although not standardised, _LLP64 (windows) and _LP64 (just about
    everyone else) macros can and often are used to define the memory model
    used on 64 bit platforms.

    --
    Ian Collins.
    Ian Collins, Jan 27, 2007
    #6
  7. David T. Ashley wrote:
    > I looked up this file (<stdint.h>) on my Linux
    > box, and it is just what I was looking for.
    >
    > However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
    > the include directory, so just to be sure I wasn't missing something, I
    > searched Microsoft's site by "stdint.h" and got no matches.


    Take a look at Boost[1]. While it's mainly a C++ library, it also has a
    compatibility module for platforms lacking explicitly sized integers. If
    it doesn't already work for C, you will probably be able to easily make it
    work.

    One thing though, which wasn't brought up yet: it is best to avoid such
    types. Depending on the context, it might be necessary though.

    Uli

    [1] www.boost.org
    Ulrich Eckhardt, Jan 27, 2007
    #7
  8. David T. Ashley

    Ian Collins Guest

    Ulrich Eckhardt wrote:
    > David T. Ashley wrote:
    >
    >>I looked up this file (<stdint.h>) on my Linux
    >>box, and it is just what I was looking for.
    >>
    >>However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
    >>the include directory, so just to be sure I wasn't missing something, I
    >>searched Microsoft's site by "stdint.h" and got no matches.

    >
    >
    > Take a look at Boost[1]. While it's mainly a C++ library, it also has a
    > compatibility module for platforms lacking explicitly sized integers. If
    > it doesn't already work for C, you will probably be able to easily make it
    > work.
    >
    > One thing though, which wasn't brought up yet: it is best to avoid such
    > types. Depending on the context, it might be necessary though.
    >

    Why should they be avoided?

    --
    Ian Collins.
    Ian Collins, Jan 27, 2007
    #8
  9. David T. Ashley

    CBFalconer Guest

    "David T. Ashley" wrote:
    > "Ian Collins" <> wrote:
    >> David T. Ashley wrote:
    >>
    >>> I'm writing code which will compile on multiple Windows and
    >>> multiple *nix platforms. Some will have 64-bit integers, I
    >>> believe.
    >>>
    >>> What is my best option to define platform-independent types such
    >>> as UINT32 or UINT64? I'm not sure how to sort out the various
    >>> platforms and integer sizes, and some of it may even vary based
    >>> on compiler options.

    >>
    >> Probably a good place to start would be <stdint.h> on one of the
    >> 64 bit capable systems. I think you should use the standard
    >> types, rather than redefining them in caps.

    >
    > Thanks for that info. I looked up this file (<stdint.h>) on my
    > Linux box, and it is just what I was looking for.
    >
    > However, I also have Microsoft Visual C++. I couldn't find
    > <stdint.h> in the include directory, so just to be sure I wasn't
    > missing something, I searched Microsoft's site by "stdint.h" and
    > got no matches.
    >
    > I think the Microsoft tool chain doesn't have such a file. It
    > isn't clear what to do, because even Windows will run on some
    > 64-bit platforms.


    It doesn't exist under C90, only under C99. However limits.h
    exists under both, so you could make your decisions based on the
    values in that.

    Most of the world has at least partially implemented C99, but
    Microsoft is following its usual practice of undermining
    standards. Just don't use any Microsoft software.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Jan 27, 2007
    #9
  10. On Sat, 27 Jan 2007 21:10:28 +0100, in comp.lang.c , jacob navia
    <> wrote:

    >David T. Ashley a écrit :
    >
    >> However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
    >> the include directory, so just to be sure I wasn't missing something, I
    >> searched Microsoft's site by "stdint.h" and got no matches.
    >>

    >
    >Just copy your linux stdint.h to your Microsoft installation...


    This may or may not achieve anything, depending on how stdint.h
    defines the types. You may also end up copying several other headers.
    Some of these may contain architecture-specific details which simply
    aren't portable, and you'll either end up with incorrect definitions,
    or definitions which surprise you.

    Generally headers are _not_ portable between implementations.


    >Of course you should remember that in 64 bit microsoft environment,
    >long is 32 bits and under 64 bit linux it is 64 bits. The file would
    >need at most a small editing change.


    In my view, that sorta defeats the point. If you know the widths, then
    you could just define the whole lot yourself in a private header with
    a bunch of #ifs

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, Jan 28, 2007
    #10
  11. David T. Ashley

    Guest

    On Jan 27, 12:04 pm, "David T. Ashley" <> wrote:
    > "Ian Collins" <> wrote in
    > > David T. Ashley wrote:
    > >> I'm writing code which will compile on multiple Windows and multiple *nix
    > >> platforms. Some will have 64-bit integers, I believe.

    >
    > >> What is my best option to define platform-independent types such as
    > >> UINT32
    > >> or UINT64? I'm not sure how to sort out the various platforms and
    > >> integer
    > >> sizes, and some of it may even vary based on compiler options.

    >
    > > Probably a good place to start would be <stdint.h> on one of the 64 bit
    > > capable systems. I think you should use the standard types, rather than
    > > redefining them in caps.Thanks for that info. I looked up this file (<stdint.h>) on my Linux box,

    > and it is just what I was looking for.
    >
    > However, I also have Microsoft Visual C++. I couldn't find <stdint.h> in
    > the include directory, so just to be sure I wasn't missing something, I
    > searched Microsoft's site by "stdint.h" and got no matches.
    >
    > I think the Microsoft tool chain doesn't have such a file. It isn't clear
    > what to do, because even Windows will run on some 64-bit platforms.


    Just get this:

    http://www.pobox.com/~qed/pstdint.h

    Include that file for all platforms, and you are basically done. Its
    as if all systems have a <stdint.h> at that point. Its not 100% (and
    I accept feedback on making the file better) but it covers all the
    most common, important scenarios.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
    , Jan 28, 2007
    #11
  12. jacob navia <> writes:
    [...]
    > Yes. Just copy your linux stdint.h to your Microsoft installation...


    That's vanishingly unlikely to work. Does a Microsoft installation
    happen to have headers called <features.h>, <bits/wchar.h>, and
    <bits/wordsize.h>? Does it define a macro __WORDSIZE; if so, does it
    have the same meaning as on Linux?

    > NOT very difficult. stdint.h is standard C. Microsoft dpesn't always
    > comply with it but this is easy to follow.


    Yes, stdint.h is standard C. It's also worth mentioning that it's new
    in the C99 standard, which many compilers don't currently implement.

    > Of course you should remember that in 64 bit microsoft environment,
    > long is 32 bits and under 64 bit linux it is 64 bits. The file would
    > need at most a small editing change.


    If you want an implementation of <stdint.h> that can be used with a
    pre-C99 implementation, take a look 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 28, 2007
    #12
  13. "Ian Collins" <> wrote in message
    >
    >> One thing though, which wasn't brought up yet: it is best to avoid such
    >> types. Depending on the context, it might be necessary though.
    >>

    > Why should they be avoided?
    >

    It is just a nuisance to everyone if integers aren't ints. Very rarely it is
    necessary to use a short type to save memory or a big type to hold a huge
    value, but rarely.

    ANSI have unfortunately decided that it is more important to support 4096
    million character strings on 32 bit machines than to have a clean language,
    and muddied the waters.
    Malcolm McLean, Jan 28, 2007
    #13
  14. On Jan 27, 7:09 pm, "David T. Ashley" <> wrote:
    > I'm writing code which will compile on multiple Windows and multiple *nix
    > platforms. Some will have 64-bit integers, I believe.
    >
    > What is my best option to define platform-independent types such as UINT32
    > or UINT64? I'm not sure how to sort out the various platforms and integer
    > sizes, and some of it may even vary based on compiler options.


    Start by including <limits.h>. If you want for example a 32 bit
    unsigned type, check whether UINT_MAX is 0xffffffff, if not then check
    whether ULONG_MAX is 0xffffff, otherwise #error (sort it out when you
    run into the situation).

    When running on a 64 bit system, you sometimes want 64 bit values
    instead of 32 bit, and sometimes you don't. A variable that counts the
    number of open windows in an application, or the number of children in
    a family, doesn't have to be 64 bit. Variables counting the sizes of
    things, or number of items, you will likely want to change in size on
    a 64 bit system. I'd say checking whether SIZE_MAX == 2^64 - 1 is a
    good indication. So you want some type that _does_ change on a 64 bit
    system and needs to be named appropriately.

    One hint: If you define such a type, give it a different type on a 32
    bit vs. 64 bit system. For example, don't use long in both cases, but
    use int for 32 bit (if it is large enough) and long for 64 bit (if it
    is large enough). That way you can find mistakes where the wrong type
    is used, because either on a 32 bit system or a 64 bit system the
    compiler will produce an error.
    christian.bau, Jan 28, 2007
    #14
  15. David T. Ashley

    CBFalconer Guest

    Malcolm McLean wrote:
    > "Ian Collins" <> wrote in message
    >>
    >>> One thing though, which wasn't brought up yet: it is best to avoid
    >>> such types. Depending on the context, it might be necessary though.

    >>
    >> Why should they be avoided?

    >
    > It is just a nuisance to everyone if integers aren't ints. Very
    > rarely it is necessary to use a short type to save memory or a big
    > type to hold a huge value, but rarely.
    >
    > ANSI have unfortunately decided that it is more important to support
    > 4096 million character strings on 32 bit machines than to have a
    > clean language, and muddied the waters.


    Nonsense. ISO has decided that it is important to not invalidate
    clean existing code, as did the ANSI committee about 20 years ago.
    The result has been almost 100% acceptance of the C90 standard, and
    C99 will eventually be accepted. However the urge to advance there
    is much smaller, simply because C90 did such a good job, and some
    C99 extensions are a bear to implement.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>
    CBFalconer, Jan 28, 2007
    #15
  16. David T. Ashley

    santosh Guest

    Malcolm McLean wrote:
    > "Ian Collins" <> wrote in message
    > >
    > >> One thing though, which wasn't brought up yet: it is best to avoid such
    > >> types. Depending on the context, it might be necessary though.
    > >>

    > > Why should they be avoided?
    > >

    > It is just a nuisance to everyone if integers aren't ints. Very rarely it is
    > necessary to use a short type to save memory or a big type to hold a huge
    > value, but rarely.
    >
    > ANSI have unfortunately decided that it is more important to support 4096
    > million character strings on 32 bit machines than to have a clean language,
    > and muddied the waters.


    One common complaint I hear from my colleagues, (who're Java bigots),
    in defense of their reluctance to use C, is that it's types are too
    few and primitive. I suppose it's a common argument on the bullet
    lists of advocates of 4GLs.
    santosh, Jan 28, 2007
    #16
  17. "christian.bau" <> wrote in message
    > When running on a 64 bit system, you sometimes want 64 bit values
    > instead of 32 bit, and sometimes you don't. A variable that counts the
    > number of open windows in an application, or the number of children in
    > a family, doesn't have to be 64 bit.
    >

    No, but you need a lot of open desktops or a lot of families for it to
    matter that the integer is 64 bits.
    Malcolm McLean, Jan 28, 2007
    #17
  18. David T. Ashley

    Ian Collins Guest

    Malcolm McLean wrote:
    > "Ian Collins" <> wrote in message
    >

    What happend to the other attributions?

    >>>One thing though, which wasn't brought up yet: it is best to avoid such
    >>>types. Depending on the context, it might be necessary though.
    >>>

    >>
    >>Why should they be avoided?
    >>

    >
    > It is just a nuisance to everyone if integers aren't ints. Very rarely it is
    > necessary to use a short type to save memory or a big type to hold a huge
    > value, but rarely.
    >

    From the above I guess that you haven't worked on embedded systems or
    drivers, where size very often does matter.

    > ANSI have unfortunately decided that it is more important to support 4096
    > million character strings on 32 bit machines than to have a clean language,
    > and muddied the waters.
    >

    Now that's just silly.

    --
    Ian Collins.
    Ian Collins, Jan 28, 2007
    #18
  19. santosh said:

    <snip>

    > One common complaint I hear from my colleagues, (who're Java bigots),
    > in defense of their reluctance to use C, is that it's types are too
    > few and primitive. I suppose it's a common argument on the bullet
    > lists of advocates of 4GLs.


    I'm a great fan of 4GLs, but I see type multiplicity as something of a mixed
    blessing. In any case, many of those 4GLs are written in C in the first
    place. I once used a fabulous 4GL called KnowledgeMan. The language was a
    sort of cross between C and BASIC. Types were almost non-existent, actually
    - just numbers, strings, and database records, if I recall correctly. But
    you got SQL, you got an evaluation operator for ripping the quotes off
    strings, you got a built-in spreadsheet, you could read program code off
    the disk and load it into the spreadsheet and then execute it from there
    (because, would you believe, this was quicker - using the spreadsheet as a
    sort of RAM disk)... oh, all sorts of tricks. It even had a sort of expert
    system bolted on. That was one fabulous 4GL! But lotsatypes? No.

    --
    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 29, 2007
    #19
  20. "Ian Collins" <> wrote in message
    >> It is just a nuisance to everyone if integers aren't ints. Very rarely it
    >> is
    >> necessary to use a short type to save memory or a big type to hold a huge
    >> value, but rarely.
    >>

    > From the above I guess that you haven't worked on embedded systems or
    > drivers, where size very often does matter.
    >

    When I campaign for 64 bit ints, that is on systems with 64 bit address
    buses.

    Oddly enough the last embedded system I programmed was a DSP which did have
    wide integer types and no memory to speak of. However it didn't have a C
    compiler.
    Malcolm McLean, Jan 29, 2007
    #20
    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. john smith

    void* versus uint32*

    john smith, Apr 1, 2005, in forum: C++
    Replies:
    4
    Views:
    530
    Howard
    Apr 1, 2005
  2. Andrew Markebo
    Replies:
    1
    Views:
    764
    Peter Hansen
    Nov 17, 2004
  3. Xiangliang Meng

    What does "Uint32 enum {a = 100, b = 200};" mean?

    Xiangliang Meng, Jul 13, 2004, in forum: C Programming
    Replies:
    9
    Views:
    601
    Keith Thompson
    Jul 20, 2004
  4. Lighter
    Replies:
    3
    Views:
    548
    Keith Thompson
    Oct 6, 2006
  5. Lighter
    Replies:
    4
    Views:
    361
    Frederick Gotham
    Oct 6, 2006
Loading...

Share This Page