SHMOP (SYSV) returns -1 on error

[BostonU SysMgr]

>From: "Niket K. Patwardhan" <bilbo.niket at locus.ucla.edu>
>
>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