🚀 go-pugleaf

In article <1661@bute.tcom.stc.co.uk> graham@tcom.stc.co.uk (Graham Bardsley) writes:
>Here's some other sloppyness in UNIX pointer types (by no means definative):
>	caddr_t mmap() returns -1 on error
>	char *shmat() returns -1 on error.

These two were inexcusable design botches.  The (pointer)-1 problem was
well-known when these first publicly appeared.

>	void (*signal())()  can return either -1 (error), 0 (SIG_DFL), or
>	1 (SIG_IGN) although SIG_DFL and SIG_IGN are macros :-o

SIG_ERR is the macro for the error case.  The official standards all use
the macros only; you shouldn't rely on 0, 1, and -1 (however cast)
working for these.  Your application can include the following:
	#include <signal.h>
	#ifndef SIG_ERR
	#define	SIG_ERR	((void(*)())-1)
	#endif
in order to accommodate older implementations.

>	char *mktemp() returns -1 on error

No, it doesn't, at least not on UNIX systems.  It may return a null
pointer on error, as it does on 4.3BSD, but through SVR2.0 it always
returned a pointer to the name string even if it was unable to find
a suitable file name (in which case the name string was empty).

> Just what are you meant to to test error conditions with these beasts !
>The only thing really is to cast the result to int and compare ...

Or, you can compare the pointer to ((pointer_type)-1), which "lint"
also properly complains about.  There simply is no correct, portable
way to deal with such bogus pointers.