Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!romp!auschs!awdprime!sanders.austin.ibm.com
From: sanders@sanders.austin.ibm.com (Tony Sanders)
Newsgroups: comp.lang.c
Subject: Re: Lint question
Message-ID: <1823@awdprime.UUCP>
Date: 15 Mar 90 19:50:09 GMT
References: <32699@brunix.UUCP> <90072.232413CMH117@psuvm.psu.edu>
Sender: news@awdprime.UUCP
Reply-To: sanders@sanders.austin.ibm.com (Tony Sanders)
Organization: IBM AWD, Austin, TX
Lines: 30

In article <90072.232413CMH117@psuvm.psu.edu> CMH117@psuvm.psu.edu (Charles Hannum) writes:
>
>In article <32699@brunix.UUCP>, gvr@cs.brown.edu (George V. Reilly) says:
>>
>>      if (((dx = table[n].x - x), ((dx *= dx) < min))  &&
>            ^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^
>The C compiler could calculate these expressions in any way it damned well
>feels like it.  This is not defined in the ANSI C standard, mainly because
>it would screw up optimizing compilers to have limits on the order of
>evaluation when not necessary.
Not so fast!  The only place where comma order is undefined is in
function calls.  The comma OPERATOR has left to right evaluation order.
Anyway, this problem isn't related at all to the comma operator anyway,
read on.

The problem lies not in the (self admited) ugly if statement but in the
use of "dx *= dx" itself.  For example a simple "r = (x*=x);" will also
complain of evaluation order undefined (with my lint).  While "r = (x=x*x);"
slips by lint without a word (as it should).

Sounds like a lint bug to me.

As ugly as the if statement was, it is prefectly legal code.
If you want the code to lint clean just change the "dx*=dx" to "dx=dx*dx".

However, I higly suggest rethinking the problem and make the code "cleaner".

-- sanders                          The 11th commandment: "Thou shalt use lint"
For every message of the day, a new improved message will arise to overcome it.
Reply-To: cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders     (ugh!)