Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!menudo.uh.edu!nuchat!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.std.c Subject: Re: gcc and NULL function pointers. Message-ID: Date: 21 Jun 91 14:05:10 GMT References: <16418@smoke.brl.mil> <16468@smoke.brl.mil> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 40 In article <16468@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: > In article 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?"