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