Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!cs.uoregon.edu!ogicse!intelhf!ichips!iWarp.intel.com!inews!nevin!bhoughto From: bhoughto@nevin.intel.com (Blair P. Houghton) Newsgroups: comp.std.c Subject: Re: gcc and NULL function pointers. Message-ID: <4728@inews.intel.com> Date: 15 Jun 91 20:19:40 GMT References: <1991Jun4.012914.25418@tkou02.enet.dec.com> <4641@inews.intel.com> Sender: news@inews.intel.com Organization: Intel Corp, Chandler, AZ Lines: 40 In article peter@ficc.ferranti.com (Peter da Silva) writes: >In article <4641@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes: >> Old chesnuts crack hard... And old cocoanuts post garbage... >> The most general, and therefore most valuable, way to define NULL is >> to simply map it to the digit 0. > >And you're working at Intel... So? Not everyone at Intel is on the Intel*86(tm) design teams (but I _do_ have a poster of a plot of an 80386DX(tm) behind my chair, so if you want to you can go right ahead and believe that I drew it freehand...), and I couldn't tell you if _anyone_ at Intel is the owner of the design of _any_ compiler. >On an 80x86 (x<3), there exist models where >int = 16 bits, pointer = 32 bits. On such a machine, > > execl("/bin/sh", "sh", "-c", "echo", NULL); > >(which is a common idiom in UNIX source groups) will display amazing >things, assuming you don't get a core dump... 1. I am not responsible for bad/typical/good design of compilers. 2. I am not responsible for your incorrect use of the semantics of function calls. 3. I do, however, feel responsible for your education and edification as long as you are part of my community, so I will remind you that we've been 'round and 'round the argument-size vs. parameter-size ambiguity bush, and that the standard defines this problem, even if it is a bit shrouded in documentational mumbo-jumbo. --Blair "But if you ever need an Intel186(tm)-based, custom microcontroller, give me a call and I'll explain how I'm not in sales, either..."