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