value/sign preserving

Alan Rooks alan at bk.dk
Thu Apr 14 23:12:02 AEST 1988


A short while ago, Chris Torek posted an informative summary of the value-
preserving/signed preserving question, and how it is in dpANS. He was of
the opinion that the sign-preserving rules were easier to learn, and the
"benefits" of value-preserving were marginal.

Doug Gwyn (I think) replied that sign-preserving rules weren't all that
simple, and besides, very few programs would be affected by using one or
the other model.

So it seems that one or the other is a little better/worse to use, and one
or the other is a little easier/harder to learn. But is this the issue? As
far as I can tell, using value-preserving rules changes the specification
of C in a fairly large way, not so much from K&R, which is out of date, but
from its successor C reference manuals. The first rule in the "usual
arithmetic conversions" section of the 3B2 System V Release 3 C Reference
Manual states
	
	First, any operands of type |char| or |short| are converted to
	|int|, and any operands of type |unsigned char| or |unsigned
	short| are converted to |unsigned int| ...

This is clearly the sign-preserving rules, and will change in a major way
in dpANS (please correct me and ignore the rest if this is wrong - I don't
have a copy of the draft standard).

So if we have only a very slight change/improvement, is it worth changing
the language definition? It seems to me that if X3J11 isn't getting something
major for a change, then it shouldn't change! (and maybe it shouldn't
change even if they do get something major).

Of course, maybe I have too much of a UNIX-orientation. Do other non-Unix
compilers use (and define that they use) value-preserving rules?

I am interested in this because I am writing a translator for a C-like
language, which will translate to C. The C-like language will have the
same conversion rules as C (essentially), and thus my translator will
have to have the "usual arithmetic conversions" built in to it. I don't
want to have to change all of this later! (wishful thinking, I guess).

Alan Rooks - Bruel & Kjaer Copenhagen - ...!mcvax!bk!alan or ...!dkuug!bk!alan



More information about the Comp.lang.c mailing list