From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: **
X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_20,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 11390f,4c42ac518eba0bbe
X-Google-Attributes: gid11390f,public
X-Google-Thread: 109fba,4c42ac518eba0bbe
X-Google-Attributes: gid109fba,public
X-Google-Thread: 103376,4c42ac518eba0bbe
X-Google-Attributes: gid103376,public
X-Google-Thread: 1014db,4c42ac518eba0bbe
X-Google-Attributes: gid1014db,public
From: fred@genesis.demon.co.uk (Lawrence Kirby)
Subject: Re: Programming language vote - results
Date: 1997/11/27
Message-ID: <880643794snz@genesis.demon.co.uk>#1/1
X-Deja-AN: 293166708
References: <347440AD.35DF@idt.net> <65di3v$730$1@news1.ucsd.edu>
 <347C420A.2B18@sensor.com> <65ih8m$pqt$1@news1.ucsd.edu>
X-Mail2News-User: fred@genesis.demon.co.uk
X-Complaints-To: abuse@demon.net
X-Mail2News-Path: genesis.demon.co.uk
X-Trace: mail2news.demon.co.uk 880645025 16870 fred genesis.demon.co.uk
Organization: none
Reply-To: fred@genesis.demon.co.uk
Newsgroups: comp.lang.ada,comp.lang.apl,comp.lang.c,comp.lang.c++
Date: 1997-11-27T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <65ih8m$pqt$1@news1.ucsd.edu>
           wtanksle@sdcc10.ucsd.edu "William Tanksley" writes:

...

>NULL is defined as "(void*)0".

It could also be written as #define NULL 0 in C, and it must be written like
that in C++.

> I've never seen a compiler which failed to
>have (int)NULL be equal to 0 as well, but seeing one would not shock me --
>according to K&R 2 (I don't have ANS C available right now) ANS doesn't
>explicitly require that.

That is correct - converting a pointer to an integer has
an implementation-defined result if it will fit in the integer, undefined
if not. There are no special cases for conversion in that direction.

>The worst part of that code, as far as I'm concerned, isn't the use of
>pointers as booleans; after all, I can't imagine why a vendor would EVER
>make non-zero NULL returns, especially since it would have to do a LOT of
>work to make them meet the other requirements.

Actually that's not true. All the implementor has to do is that ensure that
whenever a null pointer constant is converted to a pointer type, the
result has the correct representation for a null pointer of that type.
For comparison against zero you can simply take the view that the zero
is converted to the appropriate pointer type so the comparison simply
works.

> The bad part is that it
>assumes that a pointer in an unknown state will be either NULL or
>allocated.  Ick.  However, it could be that all the other code in the
>application is a model of clear and precise code, so those are obviously
>the only two possible states of the pointer at that point.  If so, that's
>acceptable code.

A pointer value can be one of the following in C:

1. null

2. a pointer to a valid object (or function for a function pointer)

3. a pointer to one past the end of a valid object

4. Indeterminate.

In the last case it is not valid to even look at the value in the code.
Indeterminate pointers are, for example:

1. the values of uninitialised automatic variables

2. a pointer to an automatic variable which has since been destroyed
   because the function defining it returned or was longjmp'd out of

3. a pointer to dynamic memory that has been freed

4. a pointer to a FILE that has been closed.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------