Return value from shmat(2) is not portable ?

[Ugo Cei]

[This is crossposted to comp.lang.c, since the discussion on the
pointer/integer relationship may have a wider audience than just Unix
programmers.]

>From a typical SysV shmat(2) man page:

|	  char *shmat (shmid, shmaddr, shmflg)
|	  int shmid;
|	  char *shmaddr;
|	  int shmflg;

[...]

|     Diagnostics
|	  Upon successful completion, the return value is as follows:
|
|	       shmat returns the data segment start address of the
|	       attached	shared memory segment.
|
|	       shmdt returns a value of	0.
|
|	  Otherwise, a value of	-1 is returned,	and errno is set to
|	  indicate the error.

I have always believed that comparing pointers to integers was not
portable, unless the integer is the constant 0 (which is not an
integer at all, in this context). Well, if you concede me this, how am
I supposed to test for the failure or success of shmat(2) ? Maybe:

	char * shmaddr;
	if((shmaddr = shmat(shmid, shmaddr, shmflg)) < 0)
		...

This, however, elicits a severe warning from my compiler, since I am
not supposed to do an ordered comparison of a pointer and an integer.
This is an issue that I wholeheartedly agree with. 

In the end, I have resorted to this kind of kludge:

	if((shmaddr = shmat(shmid, shmaddr, shmflg)) == (char *)(~0))
		...

I know, this is not portable either, but my eyes are much more pleased
since this resembles ``... == (char *) 0'', which IS portable. And
even my compiler has stopped complaining. Now, my question is: why on
earth wasn't shmat(2) made to return 0 (NULL) in case of failure ? Are
there some subtle reasons for this that I am not aware of ?

Inquiring mind wants to know.




-- 
**************** | Ugo Cei            | home:    newsuser at oliver.sublink.org
*    OLIVER    * | Via Colombo 7      | office:  cei at ipvvis.unipv.it
**************** | 27100 Pavia ITALY  |       "Real Programs Dump Core"