From: utzoo!decvax!harpo!eagle!mhuxt!mhuxa!mhuxh!mhuxm!pyuxjj!pyuxll!jse Newsgroups: net.unix-wizards,net.lang Title: if statement ambiguity and the C preprocessor Article-I.D.: pyuxll.282 Posted: Wed Sep 22 16:25:06 1982 Received: Thu Sep 23 04:39:38 1982 There is a problem with the kind of syntax used for if statements in languages like C that is well known, but nobody seems to complain about it too much. The problem is the ambiguity of which if an else belongs to. The standard way of dealing with this is to say that an else matches with the closest unmatched if. I always thought the better way of dealing with the problem was to use if..then..[else]..fi instead. Like many C programmers, I have grown quite used to this, and it rarely causes any problems. I like C in general, and I also like not having to type fi. The following situation is one in which it does bother me occasionally. Suppose I want to define a macro which is an if statement without an else, e.g.: #define mymacro if (e1) s1 Now I want to use it somewhere, e.g.: if (e2) mymacro; else s2; Well, this will not do what I probably wanted it to do, namely associate the else with "if (e2)". You might think that the solution is to try #define mymacro { if (e1) s1; } but that won't help either, because then the else won't be associated with any if statement at all because of the semicolon before the else. Questions: Is there some way to do this cleanly in C? Why do languages continue to be designed with this syntactical ambiguity? Does it bother anyone else? (To be fair, it doesn't really bother me that much; I just don't try to use that construction). Jan Edler pyuxll!jse (btl piscataway) cmcl2!edler (nyu)