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}