Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!jrdzzz.jrd.dec.com!tkou02.enet.dec.com!jit533!diamond
From: diamond@jit533.swstokyo.dec.com (Norman Diamond)
Newsgroups: comp.std.c
Subject: Re: gcc and NULL function pointers.
Message-ID: <1991Jun27.001642.10658@tkou02.enet.dec.com>
Date: 27 Jun 91 00:16:42 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>
Sender: usenet@tkou02.enet.dec.com (USENET News System)
Reply-To: diamond@jit533.enet@tkou02.enet.dec.com (Norman Diamond)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 19

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).  So it seems to be allowable.
Of course, only a foolish user would write code that depends on it.
--
Norman Diamond       diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Permission is granted to feel this signature, but not to look at it.