chip@ateng.ateng.com (Chip Salzenberg) (10/04/88)
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 <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (10/05/88)
I swear that the world is full of assholes who take something I wote out of context to prove how smart they are. Here's another one! In article <1988Oct4.122416.3575@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: | 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! Do you see a statement that says they are portable? Do you??!! If you have read the entire discussion instead trying to impress us with you briliance, you would see that the answer was to someone who said that (a) NULL should always be 0, and (b) if it isn't the compiler is broken, therefore (c) assuming NULL is 0 will be portable. I was pointing out that NULL is not portably 0 because (a) there are lots of implementation which don't do it that way (real world) and (b) dbANS says it will evaluate to a "pointer constant." I quoted section, page, and line number showing this, making only the point that NULL isn't zero. When I spend the time writing a carefully constructed reply, looking up references, showing someone where their logic is wrong, and being polite in the process, the least you can do is to read the whole posting before trying to show off. I'm really impressed with your cute saying to put over my terminal, here's one for you: Before you flame be sure you understand the PROBLEM and the SOLUTION I've been trying very hard to be polite in my postings the last three years, but I didn't try very hard in this one, and my personal mail message to you represents not trying at all. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
greggy@infmx.UUCP (greg yachuk) (10/06/88)
In article <1988Oct4.122416.3575@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: >Gads, not another NULL argument. ... >Please write this saying at the top of your terminal: > > +-----------------------------------------------------------------------+ > | Always cast the NULL pointer when it is used as a function parameter. | > +-----------------------------------------------------------------------+ Unless you are using ANSI prototypes. Then it *really is* irrelevant. Greg Yachuk Informix Software Inc., Menlo Park, CA (415) 322-4100 {uunet,pyramid}!infmx!greggy why yes, I DID choose that login myself
chip@ateng.ateng.com (Chip Salzenberg) (10/08/88)
William Davidsen is upset because I posted a correction to an article of his. He claims that my quotation of his article was taken out of context; perhaps this is true. If so, I apologize. Now let's get the facts straight. The original poster, long since forgotten, correctly wrote: >The computer's internal representation of a null pointer may not >be the same as the internal representation of the integer 0. Then William Davidsen wrote: > 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. To which I replied: >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! Mr. Davidsen, considering my response a flame, flames back: > Do you see a statement that says they are portable? Do you??!! [...] > I was pointing out that NULL is not portably 0 because (a) there are >lots of implementation which don't do it that way (real world) and (b) >dbANS says it will evaluate to a "pointer constant." I quoted section, >page, and line number showing this, making only the point that NULL >isn't zero. Unfortunately, Mr. Davidsen is no more correct when angry than when calm. Both K&R and the dpANS permit: #define NULL 0 (Of course, dpANS also permits "((void *) 0)" in place of "0".) The original poster made the point that when a compiler sees char *p = NULL; it may or may not move a bit pattern of all zeros into the variable "p". Regardless, the definition of NULL as an unadorned zero is quite correct. That is the reason why all NULL pointer parameters must be cast (in the absence of prototypes, of course). Perhaps Mr. Davidsen is aware of these facts. However, I felt that his posting was misleading, so I posted a correction. I am sorry that my correction has caused a disturbance. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.