Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!umich!sharkey!amara!mcdaniel From: mcdaniel@adi.com (Tim McDaniel) Newsgroups: comp.std.c Subject: Re: gcc and NULL function pointers. Message-ID: Date: 27 Jun 91 15:26:34 GMT References: <1991Jun26.053508.3634@ringer.cs.utsa.edu> <1991Jun26.134355.29334@cs.odu.edu> <1991Jun27.011959.14714@ringer.cs.utsa.edu> Sender: news@adi.COM Organization: Applied Dynamics International, Inc.; Ann Arbor, Michigan, USA Lines: 28 In-reply-to: djimenez@ringer.cs.utsa.edu's message of 27 Jun 91 01:19:59 GMT In article <1991Jun27.011959.14714@ringer.cs.utsa.edu> djimenez@ringer.cs.utsa.edu (Daniel Jimenez) writes: It won't do just to have a Pascal 'nil' in all pointer contexts, because pointers can be of different sizes. But if "nil" occurred in a context where the compiler couldn't determine the proper pointer type, an error message would be output. That would, I think, solve all the problems; both int i = nil; execl("this", "that", "the other", "and", "more", nil); would produce error messages, as I would expect. In the absence of a time machine, I think we could do #define NULL __nil today, and "__nil" could have the semantics above. I don't think this could break any strictly-conforming ANSI C programs. "__nil" could instead mean "0" or "(void *) 0" with special switches, say "-ansi -pedantic". Anyone want to suggest it to the gcc maintainers? -- "Of course he has a knife; he always has a knife. We all have knives. It's 1183 and we're barbarians." -- Eleanor of Aquitaine, "A Lion in Winter" Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel