gcc and NULL function pointers.

[Dan Bernstein]

In article <16506 at smoke.brl.mil> gwyn at smoke.brl.mil (Doug Gwyn) writes:
> In article <1146.Jun2221.20.2291 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> >I'm not sure what people are arguing here. Yes, programmers should
> >always cast NULL appropriately if they use it at all, because there
> >exist vendors which #define NULL 0. Yes, vendors should define NULL as
> >((char *) 0) or ((void *) 0), because there exist programmers who use
> >NULL without casting and it's better to detect such misuse. What's the
> >issue?
> The issue is that #defining NULL as ((void*)0) does NOT detect such
> misuse, nor does it adequately compensate for it in all cases.

Sorry, I meant compensation. It *does* compensate in *some* cases, don't
you agree? Like a whole big pile of freely availble and often useful
even if non-``standard''-conforming code, right? So it's better to stop
the bugs---and possibly crashes---in nine cases out of ten than to
pretend that all programs conform to the standard. Right?

> #defining NULL as ((char*)0) is simply wrong.

'Scuse me for thinking about backwards compatibility in a standards
group. There are still a whole bunch of unfixed pcc-based compilers
which blow up on void *, and it's perfectly reasonable for a vendor to
decide that the header files should be pcc-compatible first and
foremost, and support ANSI in ways that won't make pcc blow up. (DEC and
Convex, for instance, currently support both pcc and ANSI compilers.)

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. And
I was under the impression that (void *) and (char *) had exactly the
same internal representation and in fact semantics, except that (void *)
can't be dereferenced...

---Dan