🚀 go-pugleaf

In article <16481@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
> In article <C62C9-2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> >> What about systems where different pointer types have different sizes?
> >Then a different definition of NULL is appropriate.

> NO NO NO.  There is NO appropriate definition of NULL if your criterion
> be that it "work" without proper casting.

No, my criterion is that it allow the maximum possible amount of comp.sources
to compile and execute. If there is no definition that'll catch 100%, then
we'll have to be satisfied with 75%, or 50%. If an unadorned "0" is the best
solution, that's the one to use. If "((void *)0)" is the best solution, then
that's the one to use.

One or the other is appropriate for any given machine. Whichever one it is
depends entirely on the machine.

> If you declare it as, say,
> something that will work as an int*, then it cannot work as a char* on
> a system where different pointer types have different sizes.

That's right, and on that system you use "0". If ints and pointers *also*
have different sizes, you're screwed. Too bad.

> In other words, the problem you think you're trying to solve cannot be
> solved in general.

No, the problem *you* think I'm trying to solve can't be solved. That's OK.
Since I'm not trying to solve that particular problem it doesn't bother me.

> All this stuff was thoroughly discussed in X3J11, by the way.  The
> outcome was what you now see specified in the C standard.

Uh, huh. And that is that "0" and "((void *)0)" are acceptable.

Pick one.

Depending on the hardware and compiler.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"