Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pacbell!pbhyf!kjk From: kjk@pbhyf.PacBell.COM (Ken Keirnan) Newsgroups: comp.sources.bugs Subject: Re: Patch #2 to Pcomm v1.1 Message-ID: <3957@pbhyf.PacBell.COM> Date: 21 Sep 88 22:28:03 GMT References: <13900004@osiris.cso.uiuc.edu> <416@quintus.UUCP> <7782@bcsaic.UUCP> Reply-To: kjk@pbhyf.PacBell.COM (Ken Keirnan) Organization: Pacific * Bell, San Ramon, CA Lines: 37 In article <7782@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: >In article <416@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>In article <13900004@osiris.cso.uiuc.edu> hood@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@pbhyf.PacBell.COM