Patch #2 to Pcomm v1.1
Ken Keirnan
kjk at pbhyf.PacBell.COM
Thu Sep 22 08:28:03 AEST 1988
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
More information about the Comp.sources.bugs
mailing list