newsuser@oliver.SUBLINK.ORG (Ugo Cei) (05/07/91)
[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@oliver.sublink.org * OLIVER * | Via Colombo 7 | office: cei@ipvvis.unipv.it **************** | 27100 Pavia ITALY | "Real Programs Dump Core"