Re: C99 exact width integers usage - informal survey

On Sat, 01 Mar 2008 14:11:34 -0600, Tim Wescott <tim@xxxxxxxxxxxxxxxx>
wrote in comp.arch.embedded:

On Sat, 01 Mar 2008 08:54:18 -0800, Marco wrote:

How many developers here are using exact width integer types as defined
in C99?

If not why?

thanks
=======================
note:
This could be by using <stdint.h> or by creating your own .h file.

example for typical 32 bit CPU:

/* Exact-width integer types. C99 Standard */ typedef signed char
int8_t;
typedef signed short int16_t;
typedef signed long int32_t;
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;

Not very much, unless a customer asks. I know that I'm swimming
upstream, but here's my reasons:

* ANSI compliant compilers guarantee minimum sizes for char, int, and
long, so you can write perfectly portable code (assuming ANSI
compliance) if you observe the constraints.

Well, yes and no on the portability issue. Unless you never use the
types int and unsigned int. If you don't completely bar them from
your code, you just might mistakenly use int on a 32-bit processor and
it works just fine. Then you move the same code to a 16-bit processor
and it breaks when you try to put 100000 into it.

So you always need to use long and short, never int, if you want
portability.

* Many DSPs have a native word size longer than 8 bits, and there's a
few from Freescale that come in increments of 24 bits. So I can't
write portable code for my market using int8_t that's not misleading.

Yes, there are architectures widely used in embedded systems, mostly
DSPs, that have a byte size of 16, 24, or 32 bits.

That's why the exact sized int types are not required in C99 unless
the implementation has those exact width 2's complement types. But
the "int_least#_t" and "int_fast#_t" types are required on all
implementations, for 8, 16, 32, and 64 bits.

As I said in my reply to the OP, I've written both ends of the parsing
and formatting code for CAN (and other binary) communications
interfaces, where code has to be pulled out of, or packed into, an
arbitrarily aligned octet stream. One end was a 32-bit ARM with 8-bit
bytes, the other end a TI 2812 DSP with 16-bit bytes. I used
int_least8_t on both sides, and the same code compiles, and runs, on
both sides.

Ultimately these 'exact width' integers foster a delusion of exactitude,
but they don't provide the real thing. Using char, short, int and long
gives me certainty of minimum size (assuming ANSI C), and if I absolutely
have to depend on a variable being some exact width then I either mask it
myself, use exact width specifiers (with tart comments about non-
portability to odd-word-length processors), or put that particular
section of code in a file that clearly indicates the limits to
portability.

I fail to see what you mean by "delusion of exactitude". On a
Freescale 56K DSP with 24-bit bytes, none of (u)int#_t exist for 8,
16, 32, or 64 bits. But the (u)int_least#_t and (u)int_fast#_t types
do. The exact width type definitions do not exist in stdint.h if the
architecture does not natively support the underlying types.

It is quite simple to build a usable stdint.h header, in some cases
excepting the 64-bit types, for any conforming C compiler all the way
back to the original 1989 ANSI standard.

--
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.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
.

Relevant Pages

  • Re: Optimization
    ... is said in books that size of int is 16-bit. ... This is the old "you should use exact sizes for your integers if portability is important" argument, which is just another way of stating "you should fix the exact platform you expect to run on to get portability". ...
    (comp.lang.c)
  • Re: Boost process and C
    ... Using size_t is also not any more *portable* than using int. ... of portability is merely a reflection of the lack of the intrinsic ... I've gotten plenty of feedback over its lifetime which has ... "Cursed with non-portabilities" indeed ... ...
    (comp.lang.c)
  • Re: Basic questions
    ... The compiler is allowed to insert padding bits wherever it likes ... > As 16 is an int, what you wrote is equivalent to ... if the OP uses 'unsigned short' only to store 16-bit numbers (writing ... values, so they're not a panacea for portability, and they might trick ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Moving from C++ to VC++
    ... If you care about ... not some abstract notion of portability. ... probably still sit on 8bit 'int'. ... > size, index, or anything having to do with capacity in a data structure, ...
    (microsoft.public.vc.language)
  • Re: Future FASMLIB website
    ... C only allows three definitions for "int", ... count on long long because we aren't guaranteeing to the assembly ... though portability across different libraries under ... Assembly programmers will be explicitly familiar with the architechture ...
    (alt.lang.asm)