Xref: utzoo comp.sources.bugs:1322 comp.lang.c:13076 Path: utzoo!attcan!uunet!ateng!chip From: chip@ateng.ateng.com (Chip Salzenberg) Newsgroups: comp.sources.bugs,comp.lang.c Subject: Re: NULL again Message-ID: <1988Oct4.122416.3575@ateng.ateng.com> Date: 4 Oct 88 16:24:15 GMT References: <7782@bcsaic.UUCP> <25069@teknowledge-vaxc.ARPA> <12246@steinmetz.ge.com> <7972@umn-cs.CS.UMN.EDU> <12269@steinmetz.ge.com> Followup-To: /dev/null Organization: A T Engineering, Tampa, FL Lines: 25 Gads, not another NULL argument. According to davidsen@steinmetz.ge.com (William E. Davidsen Jr): >| The computer's internal representation of a null pointer may not >| be the same as the internal representation of the integer 0. > > Just not true in the real world. There are hundreds of programs >written by "all the world's a VAX" types who use NULL as a pointer >(uncast) in procedure calls. That's true but irrelevant. THOSE PROGRAMS ARE NOT PORTABLE. After all, bitwise representation is not the only issue. Sometimes pointers are _larger_ than ints! Please write this saying at the top of your terminal: +-----------------------------------------------------------------------+ | Always cast the NULL pointer when it is used as a function parameter. | +-----------------------------------------------------------------------+ Followups to /dev/null, since that's where counter{flames,arguments} belong. -- Chip Salzenberg or A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.