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