🚀 go-pugleaf

In article <16468@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
> In article <MR0CV2H@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> >Yes, it's better that everyone write correct code. But be liberal with
> >what you accept... after all, the person you're punishing with a B&D
> >definition of NULL is your customer.

> You're NOT doing your customer any favor by catering to his misconceptions.

"My" customer [1] here isn't the one who wrote the code. The code may have been
written years ago on a VAX, by some grad student hacker who'd never used
anything else. "My" customer is simply trying to get "elm" [2] to compile on his
80286 based Xenix box. "He" isn't going to be satisfied by some ivory tower
assertion that the bug is in "elm" ("he" knows that already) and he should
spend the next week grovelling through the code fixing the bug for his own
good. "He" has other work to do.

> What about systems where different pointer types have different sizes?

Then a different definition of NULL is appropriate.

> There is no way the implementation can fully compensate for the programmer
> having incorrectly coded his use of the NULL macro,

True. But if there are cases where an implementation *can* do so, it should.

"be liberal with what you accept, conservative with what you generate"

> and by trying to
> accommodate such abuse at all you're merely reinforcing the mistaken notion
> that caused the programmer to make the mistake in the first place.  Sooner
> or later it is going to catch up with him, and the sooner the better.

The programmer in question will probably never use this compiler or hardware.
Why punish the innocent victim of his code?

[1] For "My" customer, "he", etcetera... read "me".
[2] For "elm"... read "elm". Horrible code.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"