Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cca!g-rh
From: g-rh@cca.CCA.COM (Richard Harter)
Newsgroups: comp.lang.c
Subject: Re: Query: Implementation with non-zero NULL
Message-ID: <16314@cca.CCA.COM>
Date: Mon, 1-Jun-87 19:46:05 EDT
Article-I.D.: cca.16314
Posted: Mon Jun  1 19:46:05 1987
Date-Received: Wed, 3-Jun-87 03:18:32 EDT
References: <158@delftcc.UUCP> <3673@gitpyr.gatech.EDU>
Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge, MA
Lines: 67
Keywords: C, NULL, portability
Summary: Prime C

In article <3673@gitpyr.gatech.EDU> allen@gitpyr.gatech.EDU (P. Allen Jensen) writes:
>In article <158@delftcc.UUCP>, henry@delftcc.UUCP (Henry Rabinowitz) writes:
>> In such an implementation, does
>> 	char *p; p = (char *)0;
>> result in p having the special null value?  How is NULL defined?
>> 
>> Are static pointers initialized to all bits zero or to the null value
>> (as in ANSI spec)?
>> 
>> In such an implementation, can you use the conventional abbreviation
>> 	if (p)
>> to mean
>> 	if (p != NULL)
>
>
>On the PRIME system under PRIMIX, there is a special "undefined pointer"
>value.  This value is used by the procedure call mechanism when fewer
>arguments are passed to a subroutine by reference (ie FORTRAN) than
>are expected.  Because of this, constructs such as the
>
>       if(p)
>
>Do not yield correct results.  The prime also has modes of operation in which
>pointers are 48 bits even though long, int and float are all 32 bits.
>This is a hold-over from the segmented addressing of the older 16 bit primes.
>
	I don't believe this is quite correct.  Our software is written in
C and runs under UNIX, VMS, and PRIMOS, so we get to get bitten by a lot of
these things.  (Other than tests we don't run under PRIMIX, since I'm not
so young as I used to be, and I'm always afraid that I won't be around when
the output shows up.)  The if(p) construct is supposed to work by definition
of the C language, and it does, if p is null.  Accessing an undefined pointer
in C will cause a system trap.

	As of the 19.4 C compiler all pointers are 48 bits.  In versions of C
prior to 19.4, char pointers were 48 bits and short, int, and long were 32
bits (don't know about structs).  As you may imagine, code which is sloppy
about pointers doesn't port too well to the Prime.  Generally speaking, if
your code is lint-clean you won't have portability problems with pointers.

	The big bugaboo in porting to the Prime is that they have messed
with the standard C library (under PRIMOS).  Argument sequences are changed
in some cases, and the older manuals were flatly wrong in places.  As a
practical matter, programs which do not isolate file opens and closes will
be a mess to port.

	Another difference which can dramatically impact portability is that
PRIME uses '8 bit ascii'.  What this means is that the high order bit is 
turned on in all character data.  If you use 0xa instead of '\n' you are
in for an unpleasant surprise.

	Still another trap for the naive UNIX C programmer is that stream
files (which are called SAM files under PRIMOS) are stored with an automatic
compression mode in which a tab character signals that the next byte is a
count byte giving the number of blanks that the pair is to be replaced with.
If you create a file with fopen/fprintf/fclose and then go back and read it
with open/read/close you are in for another little surprise.


>The value of NULL is 0x60000000 on a prime.
>
>P. Allen Jensen


-- 

Richard Harter, SMDS Inc. [Disclaimers not permitted by company policy.]