Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!ll-xn!cit-vax!oberon!castor.usc.edu!blarson
From: blarson@castor.usc.edu.UUCP
Newsgroups: news.software.b,comp.lang.c
Subject: Re: News for Xenix on PC AT ?
Message-ID: <1701@castor.usc.edu>
Date: Thu, 23-Apr-87 19:54:36 EST
Article-I.D.: castor.1701
Posted: Thu Apr 23 19:54:36 1987
Date-Received: Sat, 25-Apr-87 08:29:18 EST
References: <18346@ucbvax.BERKELEY.EDU> <145@sds.UUCP> <17005@sun.uucp> <146@sds.UUCP>
Reply-To: blarson@castor.usc.edu.UUCP (Bob Larson)
Organization: USC AIS, Los Angeles
Lines: 66
Xref: utgpu news.software.b:512 comp.lang.c:1804

In article <146@sds.UUCP> dave@sds.UUCP (dave schmidt x194) writes:
>In article <17005@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
>Why is "if (charptr == 0)" NOT identical to "if ((int)charptr == 0)" ???

Because it is identical to if(charptr == (char *)0) by the specifications
of the C language.  (K&R, H&S, and ANSI all agree on this.)
They differ because
>This would not work on a machine where sizeof(char *) > sizeof(int).

>In fact, since we are comparing apples (char *'s) to oranges (int's),
>a cast is called for and a good, conscientious programmer would perform
>the cast themself.  
And a good concientions compiler writer would write a compiler that compiles
the langue in question, not something vaugly resembling it.

>Furthermore, "if (!charptr)" is not correct on all 
>architectures: I've heard tell of an implementation of C where NULL was
>0xffffffff -- the simple "if (!charptr)" fails in this case.

Such architecutal oddities MUST be covered by the compiler/runtime system.
A cast from an int to a pointer NEEDS to convert 0 to the approprate
unusable pointer.  Redefining NULL does not redefine C.  A compiler that
does not handle this is not a C compiler.

>Coding the above as "if (charptr == (char *)NULL)" saves you from the
>"queer machine"; it is also more correct in that it explicitly states what
>you desire and is more portable.  

Writing code to avoid everything that is broken in some compiler is impossible.
Why bother trying?

>Actually, if NULL is *correctly* defined
>in stdio.h as "(char *)0" (NULL being the value that malloc() returns
>on error, NULL *should* have type char *), this could be written as
>"if (charptr == NULL)".

No, NULL should be defined as 0.  Comparisons and assignments to ANY pointer
type then work correctly, by definition.  Remember, "if(intptr == NULL)" should
work too, and "int *" and "char *" are NOT the same type.

>Unfortunately for me, XENIX correctly defines
>NULL, leaving me to deal with statements such as:

You mean uncorrectly.

[example deleted]

>This implicitly
>assumes that NULL is #defined as 0, which is an assumption that
>good programmers (or should I say "programmers that I regard as good"?)
>don't make.

Yes, there are some broken stdio.h's out there, and NULL should be used only
as a pointer value.

>Dave Schmidt
>
>(A firm believer in defensive programming.)

You avoid the bugs in your compiler, I'll avoid the bugs in mine.  Don't
expect me to agree that the language has been redefined by a broken compiler.
-- 
Bob Larson
Arpa: Blarson@Usc-Eclb.Arpa
Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson
			seismo!cit-vax!usc-oberon!castor.usc.edu!blarson