Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!camelback!volpe
From: volpe@camelback.crd.ge.com (Christopher R Volpe)
Newsgroups: comp.std.c
Subject: Re: gcc and NULL function pointers.
Message-ID: <20969@crdgw1.crd.ge.com>
Date: 27 Jun 91 21:19:51 GMT
References: <25572@well.sf.ca.us> <1146.Jun2221.20.2291@kramden.acf.nyu.edu> <16506@smoke.brl.mil> <17605.Jun2607.39.3591@kramden.acf.nyu.edu> <1991Jun27.001642.10658@tkou02.enet.dec.com>
Sender: news@crdgw1.crd.ge.com
Reply-To: volpe@camelback.crd.ge.com (Christopher R Volpe)
Lines: 36

In article <1991Jun27.001642.10658@tkou02.enet.dec.com>,
diamond@jit533.swstokyo.dec.com (Norman Diamond) writes:
|>In article <17605.Jun2607.39.3591@kramden.acf.nyu.edu>
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
|>>In article <16506@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
|>>>#defining NULL as ((char*)0) is simply wrong.
|>>
|>>By the way, I'm curious: Why is ((char *)0) ``simply wrong''? Remember
|>>the as-if rule: unless you can exhibit a working program whose results
|>>depend on whether (void *) or (char *) was used, there's no problem.
|>
|>This particular argument by Mr. Bernstein seems to be correct.
|>I would say that #defining NULL as ((char*)0) is ugly and morally repugnant,
|>but not simply wrong.  A strictly conforming program could not detect if the
|>processor has #defined NULL as ((char*)0) (as long as the processor takes
|>other necessary steps in conjunction with this, such as allowing implicit
|>coercion to and from other pointer types).

I believe the following is true:

(1) The following code is strictly conforming:
  struct foo *fooptr = NULL;

(2) The following code requires a diagnostic:
  struct foo *fooptr = (char *)0;

because an explicit cast is required to convert an expression of type
(char *) to one of type (stfuct foo *).

Therefore, if the implementation #defines NULL as (char *)0, it's
going to have a helluva time maintaining (1) and (2) above. 
                   
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com