Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!root%bostonu.csnet@CSNET-RELAY.ARPA From: root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr) Newsgroups: net.unix-wizards Subject: Re: Re: SHMOP (SYSV) returns -1 on error Message-ID: <2414@brl-tgr.ARPA> Date: Thu, 24-Oct-85 17:16:44 EDT Article-I.D.: brl-tgr.2414 Posted: Thu Oct 24 17:16:44 1985 Date-Received: Sat, 26-Oct-85 04:22:16 EDT Sender: news@brl-tgr.ARPA Lines: 31 >From: "Niket K. Patwardhan"> >I thought that every SYSTEM CALL returned -1 on error. For example, read >returns -1 if you give it a fid that hasn't been opened, is not readable etc. >EOF is NOT considered an error, and is signalled by a 0 return. Thus SHMOP >returning -1 on an error would be consistent with all other system calls. The real problem here is that very few system calls return pointers. There is a broader C convention that says that on failure routines which would return pointers return NULL because of the problems of representing -1 as a pointer in all cases (and, conversely, the promise that NULL is unique among pointers [please, let's not rehash that here.]) The de facto convention has two rules and goes something like: Routines which would return an integer return -1 on failure Routines which would return a pointer return NULL on failure Yes, this is shakey ground, as Doug Gwyn noted to me, about the only other candidate in UPM(II) (sbrk()) returns -1 also, tho it is very old. Also, as far as I know this convention has never been codified as a UNIX system call standard, perhaps only a C convention. Even the above leaves something to be desired (consider atoi()). So, you are not wrong, you may even be right. You may be stating the way it works while I am stating the way it seems it should have worked. The upshot is: Don't take it too seriously, you'll lose your mind. -Barry Shein, Boston University