Path: utzoo!mnetor!uunet!mcvax!diku!dkuug!bk!alan From: alan@bk.dk (Alan Rooks) Newsgroups: comp.lang.c Subject: value/sign preserving Message-ID: <36@bk.dk> Date: 14 Apr 88 13:12:02 GMT Organization: Bruel & Kjaer, DK-2850 Naerum, Denmark Lines: 40 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