minow@decvax.UUCP (Martin Minow) (04/24/84)
As has been pointed out "a/*b" is different from "a/(*b)" and "a / *b". The C language standard states fairly clearly that lexical tokens are disambiguated by the longest possible parse. Hope this clarifies the problem. By this rule "a+++b" means "(a++) + b". Martin Minow decvax!minow
jgw@maxvax.UUCP (04/25/84)
a++++++++++++++++++++++++++++++++++++b - eat this! I am not convinced that a+++b should be resolved as (a++) + b. K&R states that unary operators have a higher precedence than binary ops, and that the former bind right to left. Should not the above be disambiguated as a + (++b)? However it is well known that the semantics of a language and its implementation by a compiler are not always the same ( shock! ). Our compiler (UNIX V) evaluates as (a++) + b. Have you tried a-----b ??? Any programmer worth their salt, never meets these problems due to their judicious use of spaces and parentheses!!! John Weald.
stuart@gargoyle.UChicago.UUCP (Stuart Kurtz) (04/25/84)
You should notice that without spaces, it doesn't matter how you resolve the ambiguous construct a+++b, there can be at most three +'s (or -'s) there. The point is that a++ is an expression, not a variable (an lvalue, not an rvalue -- if it matters). Curiously enough, if you add spaces (or parentheses) you can get five consecutive +'s or -'s, e.g., a++ + ++b. Cheers. Stuart Kurtz.
arnold@gatech.UUCP (Arnold Robbins) (04/26/84)
The a/*b problem under discussion is from the PREPROCESSOR, not in
the lexical analyzer, (although, as far as I know, it can handle it).
That is why the message is 'missing endif', only the cpp has endif's.
The cpp strips comments.
Admittedly, that is a bozo error message, but at least know where the
problem is!
Ever look at what comes out of the preprocessor? Try it sometime.
Pretty enlightening...
--
Arnold Robbins
CSNET: arnold@gatech
ARPA: arnold%gatech.csnet@csnet-relay.arpa
UUCP: ...!{akgua, allegra, rlgvax, sb1, ut-sally}!gatech!arnold
"Come on, Jerry, the accumulators are crackling with barely restraind power!"steven@mcvax.UUCP (Steven Pemberton) (04/26/84)
> Any programmer worth their salt, never meets these problems due > to their judicious use of spaces and parentheses!!! Now this comment may have been meant as :-), and if so I'm sorry about this. In the now legendary tale of the loss of a NASA flight because in FORTRAN DO 10 I=1,10 and DO 10 I=1.10 look so similar and have such different effects, I blame FORTRAN and not the programmer for the loss. Computers should serve people, not vice versa. This is one of the reasons I feel so uneasy when using C; there are so many potential pitfalls! When I program I want to think about the problem at hand, and not whether I should type an extra space here or not. A piece of code can look so harmless and yet be completely different to what you expect. If some future NASA flight, or Cruise missile come to that, should fail because its programmer had written rate= *a/*b /*some comment here*/; I'm going to blame C, and not some poor fool who's been let down by a programming language. You sometimes see the remark "I like C because it lets me do what I want". Now, I'm all for a programming language letting you do want you want, but one of the reasons I don't particularly like C is because it just as easily lets me do want I don't want. My perfect programming language would do both. Steven Pemberton, CWI, Amsterdam; steven@mcvax. (On second thoughts, in the case of a Cruise missile going wrong, I'd blame the programmer too, for being involved.)
jcz@ncsu.UUCP (John Carl Zeigler) (04/29/84)
>
Blaming the programmer vs. blaming C for
things like "a/*b" begs the question. If you are good at your
job and take care writing code that is clean and
managible, then you wont have problems like "a/*b".
If you understand how the tools you use work, then you should
see something like "a/*b" as soon as you type it.
Of course, there is the occasional typo, but that is not
what we are talking about.
If the tools you use enable you to produce better code, then they
are good tools. If they do not make it easier to produce good code,
then they are bad tools. I would list C in the former group
because it does allow you to produce good code (by any standard -
readibility, efficiency; perhaps not orthagonally).
The only caveat is that you must have a lot of experience
with C to really know how to take advantage of these things.
John Carl Zeigler
North Carolina State Universitygwyn@brl-vgr.ARPA (Doug Gwyn ) (05/02/84)
I would like to know what combination of C language rules forces the parsing of a+++b as a++ + b rather than a + ++b I hope the C Language Standards Committee has addressed this issue.
jreuter@cincy.UUCP (Jim Reuter) (05/07/84)
Concerning *a/*b: Actually, the longest lexical token rule isn't necessarily causing the /* to be taken as a begin-comment symbol, at least on Unix systems. The C preprocessor strips comments before handing the code to the first pass, so the preprocessor lexical interpretation is actually the culprit here, not the compiler lexical pass. What's wrong with using disambiguating spaces anyway? They sure make things more readable. Jim Reuter (decvax!cincy!jreuter)
gary@mit-eddie.UUCP (05/07/84)
It seems that the lexer returns the LONGEST possible token; therefore ++ + instead of + ++. I played with this a little, thinking that a = b+++++c would work; but, it doesen't because it is parsed as a = b++ ++ +c instead of a = b++ + ++c. The longest interesting sequence of + and - with no spaces that I came up with: a = b+++-++c which works out as a = b++ + -(++c). Gary Samad decvax!genrad!mit-eddie!gary