Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlvd.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!seismo!mcvax!ukc!warwick!rlvd!mike From: mike@rlvd.UUCP (Mike Woods) Newsgroups: net.lang.c Subject: Re: if(p) Message-ID: <812@rlvd.UUCP> Date: Thu, 26-Sep-85 07:28:26 EDT Article-I.D.: rlvd.812 Posted: Thu Sep 26 07:28:26 1985 Date-Received: Mon, 30-Sep-85 00:52:35 EDT References: <1671@brl-tgr.ARPA> Reply-To: mike@rlvd.UUCP (Mike Woods) Organization: Rutherford Appleton Laboratory, Atlas Buildings, U.K. Lines: 19 Followup-To: Xpath: warwick ubu In article <1671@brl-tgr.ARPA> ART@ACC.ARPA (Art Berggreen) writes: >From an abstract language viewpoint, an "if" statement conditionally >executes a block of statements based on whether the control statement >evaluates to a condition of *TRUE*. Pointers by themself do not >have attributes of TRUE vs FALSE. Thus, "if(pointer)" makes less semantic >sense than "if(pointer == SOME_VALID_POINTER_VALUE)". What to test against >has been discussed in previous messages. But from an abstract viewpoint, pointers can be considered to have two states: valid or invalid. Therefore, "if (pointer)" can be read as "if (pointer is valid)". At least this is how I look upon such things (though the first time I saw it my mind stopped functioning for five minutes (the legacy of Fortran!)). Mike (I don't think logically; I think C) Woods. -- UK JANET: mike@uk.ac.rl.vd UUCP: ..!mcvax!ukc!rlvd!mike