Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.std.c Subject: Re: (char *)(-1) Keywords: pointers, casts Message-ID: <10649@smoke.BRL.MIL> Date: 2 Aug 89 18:15:29 GMT References: <2619@yunexus.UUCP> <18792@mimsy.UUCP> <120@psitech.UUCP> <10637@smoke.BRL.MIL> <1661@bute.tcom.stc.co.uk> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 33 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 #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.