Re: Sizes of Integer Types

Kelsey Bjarnason wrote:

[snips]

On Tue, 11 Sep 2007 17:59:28 -0500, Stephen Sprunk wrote:

You're still missing the point. If I want to write code that is only
portable to systems that have a 32-bit integer type, then the easiest
way to get that data type is to use [u]int32_t.

Which deals with one type. You can, of course, guarantee that this
system
_also_ has, oh, 8 bit integer types, right? No? So all that code
using uint8_t now has to be scrapped or rewritten, because the types
simply aren't available.

No. It is not an all-or-nothing proposition.
If I need a type with exactly 32 bits somewhere in a program, I use
[u]int32_t *at that location*. For all other variables that don't
require an exact width, I use the regular types (or the [u]int_{fast
least}N_t types).

If I need exact-width types of 8, 16 and 32 bits, then either I am doing
something wrong, or my program in inherently non-portable.


By the time you get to the point where all these new types make sense,
you've essentially restricted C to existing only on 32-bit x86
machines or
close equivalents. Hardly sensible.

Except that uint8_t does not need to exist if I only needed a 32-bit
exact width type. So my program is still portable to platforms that do
provide 32-bit integers, but not 8-bit integers.


Note that I didn't say
an integer type of "at least" 32 bits, which is what I'd get if I
used
"long". If I'm relying on a variable being exactly 32 bits, no more
or less, I cannot use a long for that purpose.

Nor can you rely on the new types, as they may well simply not exist
on
a given implementation. Yes, and?

If you used the exact-width types correctly (i.e. only when least-width
is not good enough), then you find out at compile-time that your
program can not be ported to that platform without major
rethinking/rework.

If you stuck to the existing types, at best you had found out with a
code review. More likely during testing and at worst only after
delivery of the system to your customers.

One area where the exact-width types can be beneficial, IMHO, is in the
implementation of protocol stacks, where the protocol definition is
octet oriented.
If your target platform does not have an 8-bit data type, you will have
to jump through a lot of complicated hoops to implement the protocol
correctly (where the hoops may depend on the width of the types that
you do have). Adding all these hoops to your implementation while there
is no need for them (all targeted platform support an 8-bit type) will
only increase your development cost and decrease performance.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
.

Relevant Pages

  • Re: FAQ Topic - How do I format a date with javascript? (2009-02-26)
    ... JavaScript has no integer type and no unsigned type; and PadString will ... Code should be indented, the FAQ says. ... ordered list of ordered lists. ...
    (comp.lang.javascript)
  • Re: sizeof(x) in C and in C++
    ... jimjim wrote: ... > I was reading the C++ FAQ and I was astonished to learn that sizeofis ... Becasue character literal is of integer type in C and character type in ...
    (comp.lang.c)
  • Re: PLEASE HELP ME ! PLEASE
    ... The '^' operator requires operands of an integer type. ... Did you bother to read the FAQ? ... position to slap their lecturers. ... Nobody suggested he should slap his lecturer. ...
    (comp.lang.c)
  • Re: WEird Column as Int property returns Decimal!!
    ... sproc body ...) ... numeric data type is equivalent to the decimal data type. ... Now, I have this, which returns an Integer type. ...
    (microsoft.public.sqlserver.programming)
  • Re: Sizes of Integer Types
    ... Kelsey Bjarnason wrote: ... way to get that data type is to use int32_t. ... close equivalents. ... an integer type of "at least" 32 bits, which is what I'd get if I used ...
    (comp.lang.c)