SHMOP (SYSV) - really shmat(2)

[Roger J. Noe]

> char *shmat(...)
> ...
> Upon successful completion, the return value is as follows:
> ...
> Otherwise, a value of -1 is returned...
> ---
> Yup, sure does, about the only one like it I know of, test has to go
> something like:
> 
> 	if(((int) (foo = (footype) shmat(args))) == -1) error...
> 
> anyone know any good reason why it (peculiarly) doesn't return NULL on
> failure? Even that use of an (int) cast isn't quite right, long may be
> closer, maybe, or some union tomfoolery. I would understand if this
> were old but it isn't. I doubt very much NULL is a reasonable return
> value on success. (note: SYSVR2/3B2 if it makes any difference.)
> 
> 	-Barry Shein, Boston University

I prefer to test:

	char *cp;
	if((cp = shmat(...)) == (char *)(-1))
		perror("UNIX System V IPC system calls suck");

But what worries me is that the (char *)(-1) might be a legitimate value for
a pointer to a character.  I think only NULL is required by the language to
never point to anything.  The bit pattern for (char *)(-1) could conceivably
be indistinguishable from a successful return value.  Why is this not NULL?
Because little minds stuck to their foolish consistency that all system calls
should return -1 upon failure.  What they forgot was that all system calls
should return integers!  shmat() in particular should have been allowed
another argument, type (char **) in which one could pass &cp.

The interprocess communication primitives included in System V (message
queues, semaphores, and shared memory) are all very messed up.  They were
clearly not thought out too well in either their design or implementation.
With any luck, they'll go away soon and be replaced by something that works.
--
Roger Noe			ihnp4!riccb!rjnoe