Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: news.software.b,comp.lang.c
Subject: Re: News for Xenix on PC AT ?
Message-ID: <5793@brl-smoke.ARPA>
Date: Sat, 25-Apr-87 19:23:59 EDT
Article-I.D.: brl-smok.5793
Posted: Sat Apr 25 19:23:59 1987
Date-Received: Sun, 26-Apr-87 21:55:03 EDT
References: <18346@ucbvax.BERKELEY.EDU> <145@sds.UUCP> <17005@sun.uucp> <2440@ulysses.homer.nj.att.com> <148@sds.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 33
Xref: mnetor news.software.b:545 comp.lang.c:1892

In article <148@sds.UUCP> dave@sds.UUCP (dave schmidt x194) writes:
>... 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 ...

There is no such thing as a "proper" way to do this!  The compiler may do
anything, including terminating compilation with a fatal error.  Why are
you trying to do such a thing in the first place?

>But what about K&R saying "A pointer to which 0 has been assigned is
>guaranteed not to point to any object..."?

This is meant to guarantee that the address of any object will not match
a 0 pointer, so that 0 can have the reserved special meaning of a null
pointer without problems arising.  For a straightforward implementation
of C on a nice regular architecture, this means that address 0 in the
process address space must not be assigned to any visible object by the
linker.  For UNIX systems, this is done by reserving storage at that
address within the run-time startoff header module that is linked at the
beginning of user processes.  The linker could also be kludged up to
start psect assignments at I or D address 1, 2, or whatever.

>On the other hand, if 0 cannot be a valid function address, why does
>signal not return 0 on error?

This is an artifact from the good old days when PDP-11 UNIX was the only
relevant C implementation.  Integer 0 == pointer 0 was used for SIG_DFL
and value 1 was used for SIG_IGN; being a system call, the common error
return module "cerror" was used, and it always returned integer -1.  The
"integer equivalents" 0, 1, and -1 for what are properly (void (*)())
cannot be guaranteed to be meaningful on all architectures, which is why
you should use the macros SIG_DFL, SIG_IGN, and SIG_ERR instead.  (Some
systems don't yet define SIG_ERR, but X3J11 and IEEE 1003.1 require it.)