C language portability support

[Dan Pop]

Perhaps, but I think a lot of programmers would automatically
associate the name "myDouble" with C's type "double".

That would be a downright foolish association: no point in
*unconditionally* renaming a C keyword.

If I wanted to
create typedefs for small and large floating-point types, regardless
of what the C compiler chooses to call them, I might use terms like
"small_float" and "large_float" to avoid confusion.

I can still see no confusion with mySingle and myDouble. It is sheer
stupidity to assume anything a priori about a user defined identifier.

A typedef whose name is too close to a predefined type name is
probably either redundant (if it's for the same type) or confusing (if
it isn't).

For you, maybe. To me, it conveys the message: this type is, in most
cases, the same as the C type with a similar name, but it can be something
else on unusual implementations. See again my example with myDouble
ending up as being defined as long double on an exotic implementation,
while being defined as double on most other implementations.

To take another example, "typedef unsigned char byte;" is more
reasonable than "typedef unsigned char uchar;", IMHO.

To me, they are both unreasonable, being mere aliases for standard C
types. When I read C code, I'm much happier if I don't have to deal with
such devices (despite the obvious semantics, such typedef's MUST be
checked, to be *sure* that they really are what they appear to be).

(One might
argue that "typedef unsigned char byte;" is redundant, but I might use
such a typedef to distinguish between an unsigned char holding a
character value and an unsigned char holding a fundamental unit of
storage, a distinction that C's type system, for convoluted historical
reasons, doesn't make very well.)

The actual distinction is made by using the type char for dealing with
character values and the type unsigned char for dealing with bytes.
This is why the type char hasn't been made obsolete after the introduction
of the types signed char and unsigned char.

Dan

 

[Dave Thompson]

(e-mail address removed) (Mark F. Haigh) wrote:

What the hell has this got to do with portability? First of all its
in reference to a C standard that is not widely adopted at all. So in
fact use of intN_t will specifically destroy any chance of
portability. Secondly, integers in C don't have a predescribed
implementation (like 2s complement, for example), so the int16_t on
one platform doesn't have to behave the same way as it might on any
other platform (except maybe having the same "sizeof").

C integer types in general aren't required to be 2sc, although
hardware where they aren't is very rare indeed. But the exact-width
types in particular, int<N>_t IF PROVIDED (which is not required) must
be 2sc and (uint<N>_t also) have no padding. Signed overflow (and
negative rightshift) are still up to the implementation. And they
*aren't* required to have to the same sizeof, presumably 2, since a
platform with CHAR_BIT 16 and sizeof(int16_t) == 1 is perfectly legal.

- David.Thompson1 at worldnet.att.net