List of routines safe to use in signals?

Jonathan I. Kamens jik at athena.mit.edu
Fri Dec 14 15:35:31 AEST 1990


In article <26828:Dec1404:06:4290 at kramden.acf.nyu.edu>, brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

I'll answer your last question first:

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

  Yes, I am quite sure I'm being consistent.

|> 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().

  Whenever there is an inconsistency between a man page and a library function
or system call, then the question that must be asked is, which one is wrong --
the man page or the function?

  I refuse to argue with you again about which one is wrong in the case of
close() causing EDQUOT.  I see no reason for you to bring it up again, except
just to be moderately obnoxious.  I think everyone who read that discussion
knows that my opinion is that the man page is wrong, and that your opinion is
that the function/kernel is wrong.

  I think you are intelligent enough to realize that when there is an
inconsistency between a man page and a library function, the first decision
that must be made is which one is wrong, and therefore which one needs fixing.
If you are, indeed, intelligent enough to realize that, then I can only
interpret the posting to which I am responding as a petty attempt to get me to
re-enter an old argument for no reason.  If you aren't intelligent enough to
realize that, then I'm sorry for overestimating you.

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

  This is a mild flame, btw.  Can't you just let a dead dog lie?

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710



More information about the Comp.unix.programmer mailing list