List of routines safe to use in signals?

[Dan Bernstein]

In article <1990Dec13.205957.25208 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
> In article <1990Dec13.022804.7712 at scuzzy.in-berlin.de>, src at scuzzy.in-berlin.de (Heiko Blume) writes:
> |> don't get me wrong, but there are so many things that are in the
> |> man page, but just don't work.
>   Then they should be fixed as they are found.

Exactly. Like NFS should be fixed to report EDQUOT on write(), not
close().

>   A man page for a library function is a specification for that function. 
> Degenerating a little bit, a specification for a function is also a
> specification for that function.  The definition and purpose of a
> specification in computer programming is that it tells you, as a programmer,
> what YOU need to do and what the FUNCTION guarantees to do when you call it.

Exactly. Like close() is guaranteed to return either 0 or -1 with EBADF
or EINTR. Whether the file is local or over NFS, close() *guarantees*
not to return anything else.

>   Saying that we shouldn't listen to what's in man pages because there are
> mistakes in man pages is like saying that whenever you put an answer into a
> crossword puzzle and peek at the answer key and it's different, you should
> assume that the answer key is wrong since there have been mistakes in answer
> keys in the past.

Exactly. Saying that the man page doesn't list all the possible error
returns is like saying that... well, you get the idea. So you should
always assume that what the man page says about error returns is right.

(This is a mild flame, btw. Jon, are you sure you're being consistent?)

---Dan