🚀 go-pugleaf

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