Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!dayton!rosevax!sds!dave
From: dave@sds.UUCP (dave schmidt x194)
Newsgroups: news.software.b,comp.lang.c
Subject: Re: News for Xenix on PC AT ?
Message-ID: <148@sds.UUCP>
Date: Fri, 24-Apr-87 10:34:40 EST
Article-I.D.: sds.148
Posted: Fri Apr 24 10:34:40 1987
Date-Received: Sun, 26-Apr-87 01:12:03 EST
References: <18346@ucbvax.BERKELEY.EDU> <145@sds.UUCP> <17005@sun.uucp> <2440@ulysses.homer.nj.att.com>
Organization: SciCom Data Services, Minnetonka, MN
Lines: 47
Xref: mnetor news.software.b:538 comp.lang.c:1883

In article <2440@ulysses.homer.nj.att.com>, jss@hector..UUCP (Jerry Schwarz) writes:
> In article <146@sds.UUCP> dave@sds.UUCP writes:
> >
> >Why is "if (charptr == 0)" NOT identical to "if ((int)charptr == 0)" ???
> 
> Because the language definition says it isn't.  The relevant paragraphs
> of K&R and ANSI proposal (I don't have H&S at hand)
> 
> K&R: A pointer may be compared to an integer, but the result is
> machine dependent unless the integer is the constant 0.  A pointer to
> which 0 has been assigned is guaranteed not to point to any object
> and will appear to be equal to 0 ...

OK, so the language provides that 0 has magical properties; even without
this statement from K&R, I would expect the correct cast to made.  However,
as a matter of style, I personally prefer to explicitly cast the 0 to
type char *.  This, I admit, comes from working with brain-damaged compilers
that don't always the correct conversion; some recent C compilers for the
PC family don't properly compare 32-bit pointers to 16-bit int's.  Only
the low 16-bits are checked, so you can get bit if you don't do the
cast yourself.  At this point, many of you would say "It's a compiler
problem, not my problem".  Well, if that's the only C compiler you have
at your disposal, it is your problem.  (I personally would not fork out a
couple of hundred bucks just to avoid doing a cast here and there.)
Hopefully, the company will soon
correct the problem and issue a fix in the next release.  However, would
you go to a client a say : "I'm going to be a month late for the deadline
because the compiler is brain-damanged"?  The fact of the matter is that
language specification or no, some compilers do not produce code to
conform to the specification.  Since you could be unlucky enough to 
get inflicted with one, it's a matter of good style & defensive programming
to protect yourself from such problems.

But what about K&R saying "A pointer to which 0 has been assigned is
guaranteed not to point to any object..."?  I think an exception exists
to this within the standard UNIX C library. Signal() returns a pointer
to a function; in the event of an error, -1 is returned, not 0.  As far
as I know, all other functions that return a pointer, return 0 on error.
This seems to imply that 0 may be a valid function address; not being
familiar with UNIX internals, I can't say for certain, but other O/S's
load programs such that they regard their starting address as 0.
Anyway, if function f() has starting address 0, and I cast f's address
to char *, that pointer points to something, no?
On the other hand, if 0 cannot be a valid function address, why does
signal not return 0 on error?  I would be curious to know.

Dave Schmidt