Moving C from DOS to UNIX, ANSI mistakes

[Clyde Smith-Stubbs]

>From article <64 at lcc.la.Locus.COM>, by marks at lcc.la.Locus.COM (bookmark):
> The truth is that the X3.159 Committee blew off the compatability
> goal in several places.  
>  But, do not rely on the semantics of arithmetic
> involving unsigned vars, especially where you are trying to
> assign values from one size of int to another (for example, the
> assignment "u_int = (unsigned) short" will likely NOT do what
> you intend (on a VAX).  

It never did do what you wanted. Back in 1984 (Pre-ANSI) I used a VAX
compiler (I think it was BSD4.2 based) that would sign extend when
you assigned a char to an unsigned. This was one of the reasons the
ANSI committee chose value preserving over unsignedness preserving - even
though K&R implied unsignedness preserving was the way to do it, it
was not spelled out and not all compilers conformed anyway.
(For the record, I would have preferred unsignedness preserving, but I
have come to terms with value preserving).

> I should point out that my objection to the new rule is that
> it absolutely prevents writing simple portable code which moves
> from one similar environment to another (say, one POSIX system
> to another) if any of the variables used are externally specified,
> like POSIX structure members are. 
>	[more stuff basically saying that to take something of type
>	ino_t, where ino_t is a typedef of some integral type but
>	whose length is either unknown or at least may vary from
>	system to system, there is no portable way of converting this
>	without sign extension to a longer, unsigned integral type.]

Ok, what is wrong with simply using a cast like (unsigned ino_t). This converts
the unspecified (but integral) ino_t to an unsigned of the same length. This
is then quite safe to assign without any sign-extension to any other
integral type.

The decisions made by the ANSI committee were not easy, but from what I have
seen they were considered decisions. I disagreed with some of them, but
I am prepared to work with them because any usable standard is better than
no standard at all, and the ANSI C standard is usable - it has no 
insurmountable problems I know of that are not basic to C.

-- 
Clyde Smith-Stubbs
HI-TECH Software, P.O. Box 103, ALDERLEY, QLD, 4051, AUSTRALIA.
INTERNET:	clyde at hitech.ht.oz.au		PHONE:	+61 7 300 5011
UUCP:		uunet!hitech.ht.oz.au!clyde	FAX:	+61 7 300 5246