ANSIfication: value preserving rules

Chris Torek chris at mimsy.UUCP
Tue Apr 12 09:37:06 AEST 1988


>In article <11000 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>>In find it significant that the unsigned preserving rules can be stated
>>in four words, while the value preserving rules require a paragraph
>>full of conditional wording.

In article <7651 at brl-smoke.ARPA> gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>Although I did not support the adoption of value-preserving rules
>(and AT&T's representatives vociferously opposed it),

(Oh dear: I find myself in the embarrassing position of agreeing with
AT&T :-) ...)

>I feel obliged to note that you have carefully arranged the argument
>to put the best light on your preference.

Well, naturally.  (My mother was a lawyer.  I chose the rather more
honorable profession of Unix Beach Bum, but retain a few tricks.)

>It takes more than 4 words to express the complete signedness-
>preserving rules!

To express them?  No.  To put them in a standard, yes, but to express
them, and hence to remember them, just remember that unsigned widens to
unsigned.  To remember the value preserving rules, the best I can
come up with us `unsigned widens to signed if it fits, otherwise
unsigned; it fits if there are more bits in the signed' (19 words).

[example of value-preserving being `unsurprising' deleted]

>It has been reported that when AT&T recompiled all the UNIX system
>sources with an experimental value-preserving compiler, practically
>nothing broke.

I expect the same.  In fact, since signedness is, in C, in the eye of
the evaluator, even the most serious type incompatibility---exemplified
by the (currently correct)

	% cat file1.c
	main() { f((unsigned char)0); exit(0); }
	% cat file2.c
	f(x) unsigned int x; { x = x; }
	% lint -h file?.c
	%

---will not in fact cause any harm, even for functions without prototypes.

>My experience has been that mixed-signedness expressions have tended
>to be buggy under signedness-preserving rules and that a change to
>value-preserving rules would straighten out some of the bugs I have
>encountered.

I expect the same number of latent bugs with either scheme, but I find
sign-preserving rules simpler.  In fairness, I might say that the 4BSD
compiler used to get some of them wrong, and apparently no one noticed.

>The bottom line is that this is a change we can probably live with.

Agreed.  I still think it is a botch, and I shall continue to call it
a botch.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris



More information about the Comp.lang.c mailing list