Moving C from DOS to UNIX, ANSI mistakes

[Doug Gwyn]

In article <64 at lcc.la.Locus.COM> lcc!marks at SEAS.UCLA.EDU (bookmark) writes:
>It is not possible to prevent ANSI C from sign-extending your variable
>without using a cast that would truncate your value if you later
>lengthened the type of the variable.

Surely when you change the data type of the variable, it behooves you
to also change the casts etc. in expressions that use it?

>stat which has members st_dev and st_ino which may be of any
>integral type (via dev_t and ino_t) (yes, my friends, there
>are UN*X systems with 32-bit inode numbers).  If you want to
>convert these values to unsigned for some reason, you'll have
>to write either painful or non-portable code.

Any reasonable operations with these types will preserve their values.
There has already been a problem in the UNIX environment with 16- vs.
32-bit, signed vs. unsigned, etc. types in such usages as you describe.
On balance, the problem is not made worse by adopting value-preserving
semantics, and in more typical situations unsignedness-preserving rules
are generally undesirable.

>... it would be nice if things with the same name, and similar types,
>could be used in portable expressions to get the same results.  The
>K&R unsigned rule ("unsigned always wins") provides this, ...

Not in my experience it hasn't.

Certainly, code that cares about exact bit patterns (such as your
hashing example) needs to go through excruciating pains to keep the
types appropriate for the operations.  That has always been the case.

By the way, the committee is X3J11; X3.159 is the Standard itself.