Re: Sizes of Integer Types



Kelsey Bjarnason <kbjarnason@xxxxxxxxx> writes:
On Wed, 12 Sep 2007 17:54:31 -0700, Keith Thompson wrote:
Kelsey Bjarnason <kbjarnason@xxxxxxxxx> writes:
[snips]
On Wed, 12 Sep 2007 11:34:45 -0700, Keith Thompson wrote:
Ok, show me how to write a typedef for a signed type that's exactly 32
bits wide, with no padding bits and a 2's-complement representation,
so that I don't have to change the definition for different platforms.

Oh, wait, somebody's already done that for you; it's called uint32_t.

Good. Show me where this is defined on a machine with 64-bit types.
Whoops. Doesn't exist. Next.

Show me where anybody claimed that it's defined on a machine with
64-bit types.

So we're agreed: if you rely on the new int types, you can toss portability
right out the freakin' window, and on the flip side, the "benefit" to
these types is... to avoid writing a typedef.

No, we are not agreed. Portability is not a black-and-white thing.
Sometimes portability to a subset of all possible implementations is
good enough.

Writing a typedef for an unsigned type that's exactly 32 bits wide
with no padding bits isn't terribly difficult, but it's not trivial.
Writing a similar typedef for a signed type is probably a little
harder. In fact, Doug Gwyn wrote a C90-compatible version of
<stdint.h> as part of his "q8" package.

Yes the benefit is avoiding writing a typedef. Actually, it's
avoiding *everyone* writing their own typedefs, with different names
and subtly different meanings -- see "WORD", "u32", "uint32", etc.

You suggest that it would have been better to require all these types
to be supported for all implementations, even if they have to be
emulated. That would have required substantial extra work for
implementers. It might not even be possible to emulate all the
required attributes on some systems; consider a 32-bit type with no
padding bits on a system with CHAR_BIT==9. Requiring them to exist
only where the underlying types already exist was a compromise; in my
opinin, it was a perfectly reasonable one.

A language feature of such limited apparent value that it causes this
much discussion is probably a dubious item at best, and when the only
benefit that's been offered thus far is to not have to create your own
typedef, the benefits just do not seem sufficient for this feature to
exist at all.

Most of the discussion has been in response to your stubborn refusal
to acknowledge the point.

Meanwhile the downsides are pretty obvious: use the feature, forget
portability, avoid the feature and we just end up with another "auto" or
"gets" - unwanted dross laying about cluttering things up.

So don't freaking use it. But please *try* to understand that there
are *degrees* of portability, and that partial portability can be
better than none at all.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.



Relevant Pages

  • Re: Octets with non-8 bit bytes...
    ... Being aware that complete portability across very different ... use 'typedef' or similar methods ... drivers",Alessandro Rubini, which gives a lot of good hints. ... int read_data; ...
    (comp.arch.embedded)
  • 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: Optimizing C
    ... If you're searchin for a 1 bit in a chunk of memory, ... But if you care about absolute portability (i.e., ... But unsigned types *can* have padding ... You can scan by words *if* the unsigned type you're using has no ...
    (comp.lang.c)
  • May uintN_t have padding bits?
    ... The typedef name intN_t designates a signed integer type with ... The typedef name uintN_t designates an unsigned integer type with ... Why does paragraph 1 say that intN_t has no padding bits, ...
    (comp.std.c)
  • Re: Maximum String size in Java?
    ... >> head was when I was working on unix but writing and testing code at ... I am trying to get certain co-workers to understand the value of writing ... > those that are concerned about portability and those that are not. ... My C pride and joy at the time was a web-based app that pre-dated the ...
    (comp.programming)