Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!rpi!zaphod.mps.ohio-state.edu!menudo.uh.edu!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: 27 Jun 91 13:53:16 GMT References: <16481@smoke.brl.mil> <1991Jun26.053508.3634@ringer.cs.utsa.edu> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 18 In article <1991Jun26.053508.3634@ringer.cs.utsa.edu> djimenez@ringer.cs.utsa.edu (Daniel Jimenez) writes: > I thought 0 in a context where a pointer is expected (e.g., int *p; p = 0;) > wasn't the integer 0, rather whatever that machine's representation of > a null pointer is. True, but there is a lot of broken but useful and important code floating around the net that uses NULL in contexts where a pointer is needed but an integer is expected. My claim is that it is in a compiler vendor's interest to, whenever possible, define NULL such that such code continues to work. It may not be possible. The value you need to use (either a void cast 0 or just plain 0) is system dependent. There are lots of problems. But sometimes it's possible, and when it is that's what the vendor should provide. At least until the VAXisms are all fixed (one of these decades, maybe?)... -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"