Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.std.c Subject: Re: (char *)(-1) Keywords: pointers, casts Message-ID: <10637@smoke.BRL.MIL> Date: 31 Jul 89 17:19:19 GMT References: <2619@yunexus.UUCP> <18792@mimsy.UUCP> <120@psitech.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 21 In article <120@psitech.UUCP> david@psitech.UUCP (david Fridley) writes: >> >Is it safe to return -1? >Here we see that sbrk(), a standard UNIX function, which returns a character >pointer will return (-1). That doesn't answer the question.. Of course it cannot return -1. Whether it returns (char*)-1 or some other (char*) that compares equal to -1 when cast to an int has never been satisfactorily resolved. sbrk()'s behavior is a historical remnant of the original PDP-11 implementation, when one could get away with this sloppiness. The SVID deliberately omits sbrk(), because there is no satisfactory way to specify its return value. I had been urging migration to returning a null pointer, with applications in the interim testing both for whatever they're currently testing for and for the new null pointer value. That way a transition could be made to well-defined behavior. Instead, the solution seems to have been to ask applications to limit their access to the heap to malloc()/free(), eschewing brk()/sbrk(). There is certainly no excuse for making this same error in newly designed interfaces.