Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!cit-vax!oberon!castor.usc.edu!blarson From: blarson@castor.usc.edu.UUCP Newsgroups: comp.lang.c Subject: Re: Query: Implementation with non-zero NULL Message-ID: <2480@castor.usc.edu> Date: Tue, 2-Jun-87 16:05:48 EDT Article-I.D.: castor.2480 Posted: Tue Jun 2 16:05:48 1987 Date-Received: Fri, 5-Jun-87 03:23:57 EDT References: <158@delftcc.UUCP> <3673@gitpyr.gatech.EDU> <16314@cca.CCA.COM> Reply-To: blarson@castor.usc.edu (Bob Larson) Organization: USC AIS, Los Angeles Lines: 64 Keywords: C, NULL, portability (In case you missed a few articles, the original poster was incorrect, Prime C does handle if(p), where p is a pointer, correctly. NULL is #defined to 0. The bit pattern used by a NULL pointer does not matter to correct code.) In article <16314@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: > 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. As far as I know, all versions of prime C allocate 48 bits for pointers in 64v mode. (19.2 was the first I used.) Of course, only the first 32 bits are significant on non-char pointers. 32ix mode, as supported by C 19.4-5.0, uses 32 bit pointers. (For those not experienced on primes, they support several instruction sets. 64v and 32i(x) are the two most modern.) Isn't sloppy code ALWAYS hard to port? > 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. I don't ever remember having problems with this on routines that consistant meaning between implemintations. Can you give examples of a standard routine that prime has messed up? My biggest problems have been with bugs. Does prime test their C compiler on real programs? > 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. Yup. Of course, there is a compiler option not to do this, as long as you make sure and set the high bit on any characters sent to the library routines yourself. > 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. ^Q is the character used for space compression, not tab. Also, you forgot about the null that follows a LF if needed to make the line an even number of characters, and that most primos programs will ignore any trailing spaces. Also, Prime C defaults to creating DAM files, not SAM files. >>The value of NULL is 0x60000000 on a prime. If you are going to publish the bit pattern, you should explain what the bits mean. This is a ring 3 (user mode) pointer to segment 0 address 0. The other 16 bits you missed don't matter since the extend bit isn't set. Other primos languages use an address of segment (octal) 7777 address 0. -- Bob Larson Arpa: Blarson@Usc-Ecl.Arpa Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson seismo!cit-vax!usc-oberon!castor.usc.edu!blarson