Patch #2 to Pcomm v1.1

[Ken Keirnan]

In article <7782 at bcsaic.UUCP> paula at bcsaic.UUCP (Paul Allen) writes:
>In article <416 at quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>>In article <13900004 at osiris.cso.uiuc.edu> hood at osiris.cso.uiuc.edu writes:
[ stuff deleted ]
>>
>>>! 	if (*lock_path != NULL && lock_path != NULL) {
>>
>>This only tests whether lock_path is legal *after* trying to use it!
>
>I've now seen a couple postings about this bug, but nobody has got it
>right yet!  What has been missed is that C makes no guarantee about the
>order of expression evaluation.  The only safe way to perform this test
>is using two nested if statements.
>
>I'll be quiet now.
>Paul

Paul, I quote from the UNIX System V Programmers Guide section on the
"C" Language:

    The "&&" operator groups left to right.  It returns 1 if both
    its operands evaluate to nonzero, 0 otherwise.  Unlike the "&",
    "&&" guarantees left to right evaluation; moreover, the second
    operand is not evaluated if the first operand evaluates to 0.

    The operands need not have the same type, but each must have one
    of the fundamental types or be a pointer.  The result is always
    "int".

I hope this clears up some confusion.  If your compiler produces code
that doesn't correctly evaluate the above expression, its broke.

Ken Keirnan
-- 

Ken Keirnan - Pacific Bell - {att,bellcore,sun,ames,pyramid}!pacbell!pbhyf!kjk
  San Ramon, California	                    kjk at pbhyf.PacBell.COM