karl@haddock.ISC.COM (Karl Heuer) (07/15/88)
In article <59881@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes: >[sbrk(), as well as shmop(), returns (char *)-1 on error] Neither sbrk() nor shmop() is part of the ANSI C library. I hope POSIX will fix this. >Unfortunately, we're stuck with the sins of the past, such as system calls >returning -1 even when they're returning pointers and special signal handler >values such as "(int (*)())1" (changed to "(void (*)...", which still doesn't >fix the problem in question), In ANSI C, the values of SIG_DFL, SIG_IGN, and SIG_ERR are not specified. Providing them as macros does fix the problem in question. It would seem that the correct fix for sbrk() and shmop() is to similarly provide SBRK_ERR and SHMOP_ERR. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
smryan@garth.UUCP (Steven Ryan) (07/16/88)
>Neither sbrk() nor shmop() is part of the ANSI C library. I hope POSIX will >fix this. Because ANSI is defining a language, not an operating system. A Cyber 205 doesn't need sbrk -- refer to a word and it exists, regardless of its address. And it can't use shmop -- only the site defined shared library pages can be shared (in read/execute mode). (Not that 205 is all that great or VectorC that well known, but it does provide a concrete example.)
karl@haddock.ISC.COM (Karl Heuer) (07/18/88)
[karl@haddock writes:] >Neither sbrk() nor shmop() is part of the ANSI C library. I hope POSIX will >fix this. As soon as I sent this, I realized it was misworded. What I meant was "I hope that the appropriate POSIX committee will (or did) fix the (char *)-1 problem for sbrk() and shmat(), just as X3J11 fixed it for signal()". (I'm assuming that sbrk() and shmat() are within the POSIX jurisdiction. They certainly aren't in X3J11's.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
rml@hpfcdc.HP.COM (Bob Lenk) (07/19/88)
> >[sbrk(), as well as shmop(), returns (char *)-1 on error] > > Neither sbrk() nor shmop() is part of the ANSI C library. I hope POSIX will > fix this. The 1003.1 standard includes neither sbrk() nor shmop. Sbrk() is unlikely to be covered by any standard, since nothing beyond malloc() can be defined portably or is needed for portable code (even the SVID omits sbrk() for this reason). The 1003.4 (real-time extensions to 1003.1) standard will include functionality similar to shmop, but probably not the same interface. The function similar to shmat() is currently defined to return NULL on error; in any case a non-portable cast to a -1 will never be required. One function that did require changing before inclusion in a consensus standard is signal() in ANSI C. It is defined to return SIG_ERR, and the SVID has followed this direction. Bob Lenk {ihnp4, hplabs}!hpfcla!rml rml%hpfcla@hplabs.hp.com
guy@gorodish.Sun.COM (Guy Harris) (07/19/88)
> >[sbrk(), as well as shmop(), returns (char *)-1 on error] > > Neither sbrk() nor shmop() is part of the ANSI C library. Yes, I think we all knew that, but those were the examples the previous poster used.... > >Unfortunately, we're stuck with the sins of the past, such as system calls > >returning -1 even when they're returning pointers and special signal handler > >values such as "(int (*)())1" (changed to "(void (*)...", which still > >doesn't fix the problem in question), > > In ANSI C, the values of SIG_DFL, SIG_IGN, and SIG_ERR are not specified. > Providing them as macros does fix the problem in question. Which problem is that? Given any program using those macros, you can write an equivalent program that doesn't use them by subsituting the definition of those macros for each occurrence of them, they don't intrinsically solve the problem of providing "unique" pointer values of a given type other than the NULL pointer of that type. They may make it easier for some implementations to choose techniques for providing this value other than casting integral values other than 0 to the pointer type in question (e.g., declaring some "special" objects of that type, such as "void __sig_ign__(int)"). (I suspect in practice, however, that few, if any, implementations - or, at least, few UNIX implementations - will do so, purely because of inertia.)