Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!sdcsvax!sdchem!tps From: tps@sdchem.UUCP (Tom Stockfisch) Newsgroups: comp.lang.c Subject: Re: Incrementing after a cast Message-ID: <604@sdchema.sdchem.UUCP> Date: Fri, 26-Dec-86 01:08:10 EST Article-I.D.: sdchema.604 Posted: Fri Dec 26 01:08:10 1986 Date-Received: Fri, 26-Dec-86 05:36:52 EST References: <2029@brl-adm.ARPA> Sender: news@sdchem.UUCP Reply-To: tps@sdchemf.UUCP (Tom Stockfisch) Organization: UC San Diego Lines: 100 In article <2029@brl-adm.ARPA> .csnet"@relay.cs.net> writes: >Casts are conversions? Oh? You'd never know it looking at the code that >out of my C compilers ... including Harbison's! He just regards away. > >The fact that there are machines which would like to have C compilers on >which ((sometype *)p)++ doesn't work as a "regard as" only means that >these machines aren't compatible with a lot of people's notion of C's model >of computation. Your notion that (sometype *)p could be an lvalue is not compatable with the notion of C's model of computation. As has been mentioned, even if you allow the "++" to operate on the "(sometype *)p", according to C's model of computation the cast value would exist in a temporary, and the TEMPORARY would be incremented, not p. >makes perfect legal, technical, and useful sense and these happen to be C >machines. Why lots of people with ordinary machines can't do something >useful, intuitive, and natural because some solder-crazed EE somewhere might, >just might mind you, someday do something unnatural to his memory system is >beyond me. >... >If you insist on being strict, here's a definition of ((sometype *)p)++ >which will work on any machine: > > "Think of the bits refered to as p as a (sometype *). > If don't have enough bits or you have too many bits > do something reasonable. Now increment the (sometype *) > you're thinking of. Now put the results back into p. > If you don't have enough bits or you have too many bits, > do something reasonable." > Someone posted a more precise definition that translates the construct into currently legal C. I believe it was something like ((sometype *)p)++ is defined to mean (*(sometype **)&p)++ but now I forget if the value of this expression is of the desired type. I think your definition assumes that pointers will differ only in width, and not in represention. Don't forget that on many machines the interpre- tation of a bit pattern is different for character pointers than for other types. >And no noise please about doing something reasonable because 1) we do it >all the time with numbers so why not with pointers too, 2) it's probably >what you want any way, and 3) it'll never have to be done on machines that >are reasonable to begin with. (By the way there is no reason why ((x+1) = 10) >shouldn't work too.) This violates the C design principle that an expression can be an lvalue -- what do you do with (x + y) = 10 What rule would you propose for assignments? Some rule like: expr-containing-a-single-lvalue = expr will reject the "(x+y) =" case, but then what do you do with f(x) = expr Can you think of a scheme which wouldn't double the size of C's grammar? I think that any scheme that allows "(sometype *)p" to be an lvalue in some contexts will severely complicate C's grammar. We don't want a language where the special-cases part of the definition is larger than the perfectly- general-rules section. >I forsee a day when there are two kinds of C compilers: standard ones and >useful ones ... just like Pascal and Fortran. Are we making progress yet? The usual complaint about C is that it's TOO useful. That is, that almost any combination of tokens yields a valid program (or so say its detractors), so that the compiler rarely discovers errors. Your proposal would certainly contribute to this, since it is usually an error for a cast to be an lvalue. Recall all the confusion resulting from the fact that arrays are sometimes the whole array and sometimes the pointer to the first element, and the declaration "char *p" is sometimes equivalent to "char p[]", and sometimes completely different. Do you really want cast-expressions to be sometimes lvalues and sometimes not? And the main (sole?) advantage of this extension is so you can shave two characters off the expression (*(sometype **)&p)++ I rest my case. || Tom Stockfisch, UCSD Chemistry tps%chem@sdcsvax.UCSD