Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!asuvax!ncar!groucho!steve
From: steve@groucho.ucar.edu (Steve Emmerson)
Newsgroups: comp.lang.c
Subject: Re: Problem with #define'd macro...
Message-ID: <10903@ncar.ucar.edu>
Date: 4 Apr 91 14:41:43 GMT
References: <18146@crdgw1.crd.ge.com> <18200@crdgw1.crd.ge.com>
Sender: news@ncar.ucar.edu
Organization: University Corporation for Atmospheric Research (UCAR)
Lines: 28

In <18200@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) 
writes:

>|>|>>>#define DIV_MOD(d,r,x,y) ( y == 0.0 ? d = 0.0, r = x : d = x/y, r =
>|>x - d*y )
>|>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>|>                                          This is the root of the
>|>                              precedence problem because the value "x/y" is
>|>                              being assigned to the result of the conditional
>|>                              operator, which is not an lvalue, and therefore
>|>                              an illegal target for assignment. 

>Steve Emmerson pointed out to me that the above expression is
>perfectly legal because the grammar in both K&R1 and K&R2  prevent
>parsing the ?: operator as the lhs of the assignment, thus precedence
>doesn't apply. (I put too much faith in Table 2.1). BTW, both
>GCC and SunOS cc get this completely wrong. They complain about invalid lhs
>of assignment.

Whoops!  Hang on a second!

I said the expression was valid according to the K&R1 grammar.  It is,
however, quite invalid under Standard C: it cannot be generated from
the grammar.

The original question was in the context of K&R1 C.

Steve Emmerson        steve@unidata.ucar.edu        ...!ncar!unidata!steve