woods@gpu.utcs.toronto.edu (Greg Woods) (01/30/89)
In article <5312@turnkey.TCC.COM> sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) writes: > [...] There is another change that should be made and > that is to change one of the NULL entries to a zero (0). This will remove > the only warning message that the compiler prints out. What I'm about to say is really just a flame, but at the same time, I don't want to start a war either. This is posted, instead of being mailed, out of general frustration at a very obvious mis-understanding that has perpetuated itself for far too long. The reason your compiler gives you a warning message, is because NULL has been erroneously defined as something other than just plain zero. I most definitely will not go into the reasons why, but it should suffice to say that "#define NULL 0" is the only correct definition. [Anyone who would like some evidence, please send me some mail.] The only unfortunate side-effect of this is the potential breaking of any programmes that were written with the assumption that NULL is defined as something other than zero. As another point of warning, be careful of the Microsoft C iAPX86 compiler that you are most likely using with your version of Xenix. Some versions of this compiler do not properly perform pointer arithmetic with zero, unless it is cast to a pointer type. -- Greg Woods. {utgpu,lsuc!gate,ontmoh}!woods, woods@{gpu.utcs.Toronto.EDU,utorgpu.BITNET} 1-416-443-1734 [h], 1-416-595-5425 [w] LOCATION: Toronto, Ontario, Canada
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (01/30/89)
In article <1989Jan30.013936.11995@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: | | What I'm about to say is really just a flame, but at the same time, I | don't want to start a war either. This is posted, instead of being | mailed, out of general frustration at a very obvious mis-understanding | that has perpetuated itself for far too long. What I am going to say is a flame, too. The ANSI standard for C says that NULL will return a pointer constant. Not an integer constant, *pointer*. Section 4.1.5, line 4, page 96. Please stop posting your opinion as fact. What you mean is that K&R used NULL and you wish it hadn't changed. Anyone who writes portable code never assumes integet *or* pointer, but casts it as needed and uses zero when they mean zero. | The reason your compiler gives you a warning message, is because NULL | has been erroneously defined as something other than just plain zero. I See above. "Erroneously defined" to meet the ANSI standard. | most definitely will not go into the reasons why, but it should suffice | to say that "#define NULL 0" is the only correct definition. [Anyone It should suffice to say that you are wrong. | who would like some evidence, please send me some mail.] | | The only unfortunate side-effect of this is the potential breaking of | any programmes that were written with the assumption that NULL is | defined as something other than zero. Correct! Older programs which used NULL as if it were zero will fail under ANSI compilers. So will Pascal programs. They are not 100% compatible, although it is possible to write in that set of features shared by K&R and ANSI. | | As another point of warning, be careful of the Microsoft C iAPX86 | compiler that you are most likely using with your version of Xenix. | Some versions of this compiler do not properly perform pointer | arithmetic with zero, unless it is cast to a pointer type. The effect of pointer-int is well defined, which is what I assume you mean. NULL is treated as an address, which will cause strange side effects if you think it's an int (and also if you think that a zero should be treated as an address). Your assumption that NULL was zero in K&R C (1st ed) is correct, and 2nd ed. could be read to say that, although their explanation (pg 102) states assignment and comparison with pointers. In the assumption that NULL is incorrect if defined as a pointer, you are obviously in conflict with the ANSI standard. In my opinion any code which assumed the type of NULL as either int or pointer will break on some machine. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
erc@unisec.usi.com (Ed Carp) (01/31/89)
In article <1989Jan30.013936.11995@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > > The reason your compiler gives you a warning message, is because NULL > has been erroneously defined as something other than just plain zero. I > most definitely will not go into the reasons why, but it should suffice > to say that "#define NULL 0" is the only correct definition. [Anyone > The reason why is because some idiot used "#define NULL (char)0" in the XENIX 2.1.3 SCO system (AMONG OTHERS!) NULL is, be definition, 0 and shouldn't be cast to ANYTHING! Like EOF shouldn't be cast to ANYTHING; it should just be -1 [or (-1), if you prefer]. Change your stdio.h file; please don't hack people's code -- you may be in for a surprise as to how much work that will actually take!
sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) (01/31/89)
In article <1989Jan30.013936.11995@gpu.utcs.toronto.edu>, woods@gpu.utcs.toronto.edu (Greg Woods) writes: > In article <5312@turnkey.TCC.COM> sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) writes: > > The reason your compiler gives you a warning message, is because NULL > has been erroneously defined as something other than just plain zero. I > most definitely will not go into the reasons why, but it should suffice > to say that "#define NULL 0" is the only correct definition. [Anyone > who would like some evidence, please send me some mail.] > [rest left out intensionally] If you look at the code that was modified before writing a manual on stdio.h, you would have noticed that it was made compatible with both Unix and Xenix! Nobody is arguing with you that SCO/Microsoft incorrectly defined NULL as (char *)0; however, programs which really mean zero and not a NULL pointer can easily be modified to 0 and therefore be compatible with both worlds! -- Sanford <sandy> Zelkovitz XBBS 714-898-8634 UUCP: ....att!hermix!alphacm!sandy ....trwrb!ucla-an!alphacm!sandy ....uunet!turnkey!alphacm!sandy ....ucbvax!ucivax!icnvax!alphacm!sandy DATA: 714-898-8634 VOICE: 714-894-7898
woods@gpu.utcs.toronto.edu (Greg Woods) (01/31/89)
In article <13048@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > In article <1989Jan30.013936.11995@gpu.utcs.toronto.edu> woods@gpu.utcs.Toronto.EDU (Greg Woods) writes: [That's me!] > | > | What I'm about to say is really just a flame, but at the same time, I > | don't want to start a war either. This is posted, instead of being [The war's on! :-)] > | mailed, out of general frustration at a very obvious mis-understanding > | that has perpetuated itself for far too long. > > What I am going to say is a flame, too. The ANSI standard for C says > that NULL will return a pointer constant. Not an integer constant, > *pointer*. Section 4.1.5, line 4, page 96. Please stop posting your > opinion as fact. What you mean is that K&R used NULL and you wish it > hadn't changed. Anyone who writes portable code never assumes integet > *or* pointer, but casts it as needed and uses zero when they mean zero. As I said to someone whom I did provide my evidence to: I don't have a copy of the ANSI standard. However, I have read T. Plum's summary, and find in it a clear statement that confirms that zero is still legal when used to compare or assign null pointers. He also mentions that NULL should be defined as zero, although (void *)0 is accepted. In MY opinion, NULL defined as zero cast to a pointer is only acceptable when (sizeof(int) == sizeof(void *)) is true. > | [...] > Correct! Older programs which used NULL as if it were zero will > fail under ANSI compilers. So will Pascal programs. They are not 100% > compatible, although it is possible to write in that set of features > shared by K&R and ANSI. Actually, they won't, unless the programme, or the compiler suppiled header files define NULL as something other than zero. In Unix land, are they ALL old programmes? 1/2 :-) > The effect of pointer-int is well defined, which is what I > assume you mean. NULL is treated as an address, which will cause strange > side effects if you think it's an int (and also if you think that a zero > should be treated as an address). NO, I know all about pointer-int problems.... But pointer-int comparisons are NOT the same as pointer-zero comparisons. Pointer-zero comparisons are what you are supposed to be able to do to identify null pointers. > Your assumption that NULL was zero in K&R C (1st ed) is correct, > and 2nd ed. could be read to say that, although their explanation (pg > 102) states assignment and comparison with pointers. In the assumption > that NULL is incorrect if defined as a pointer, you are obviously in > conflict with the ANSI standard. As a Unix fan, I don't give a hoot about ANSI C, and I won't until I have to use an ANSI C compiler from AT&T. :-) > In my opinion any code which assumed the type of NULL as either > int or pointer will break on some machine. I NEVER assume the type of NULL, though it is nice to have it defined as something which is the width of an int (being that all args to functions are at least that wide after the "usual conversions" are applied). I always cast NULL to the appropriate type of pointer when using it as an argument, but I NEVER want to have to cast it for an assignment, nor for a comparison. What I despise are compilers that cannot find '(some_pointer_variable_that_is_null == 0)' as true. My original faith in compilers was shattered by one such broken piece of junk. It wasn't that I'd never experienced a compiler bug before, but to have something so fundamental to the language break in some contexts, but not others really tore me up. -- Greg Woods. {utgpu,lsuc!gate,ontmoh}!woods, woods@{gpu.utcs.Toronto.EDU,utorgpu.BITNET} 1-416-443-1734 [h], 1-416-595-5425 [w] LOCATION: Toronto, Ontario, Canada