Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 (MC830713); site edee.UUCP Path: utzoo!watmath!clyde!floyd!vax135!ukc!edcaad!edee!aegl From: aegl@edee.UUCP (Tony Luck) Newsgroups: net.lang.c Subject: Bug in C compiler (?) Message-ID: <174@edee.UUCP> Date: Fri, 17-Feb-84 07:17:56 EST Article-I.D.: edee.174 Posted: Fri Feb 17 07:17:56 1984 Date-Received: Mon, 20-Feb-84 09:16:04 EST Organization: Electrical Eng., Edinburgh U., Scotland Lines: 20 [Please do not eat this line] We've just started porting emacs on our GEC 63/30 and came across the following curiosity - just in case you're not entirely fed up with people complaining about oddities in C syntax that should never come to light if people used a few more brackets in expressions I thought I'd post it to the net for you to ignore/flame about/whatever. There is a macro: #define dsputc(c) (--DSskip<0 && --left>=0 ? *cursor++ = c : 0) This causes complaints from the GEC compiler every time it is used - but the VAX 4.1 compiler (and presumably the SYS III compiler for which this version of emacs was purchased) do not object. K&R says that the assignment operators have lower precedence than "?:" so it looks as though brackets are required around the "*cursor++ = c" expression and that the 4.1 bsd compiler is wrong to accept this. [I also added brackets around the 'c' so that calling the macro with an expression as argument wouldn't muck things up too much]. Tony (let's have more brackets) Luck { ... UK!ukc!edcaad!edee!aegl}