> > No, wait, I got that wrong I think.
> >
> > Oh yah, I remember now. Hmm. How odd. I came across a case where
> > read() could return -1 and not set errno properly if errno
> > was already set, but a perusal of the kernel code seems to indicate
> > that this can't happen. Very weird.
> >
>
> I thought I saw this somewhere too, but I thought it was more of a case that
> it was somewhere *inside* read that errno had to be preserved. i.e. errno
> gets set somewhere at the top of the code, and if it was already set at a
> certain point, failure was expected, and to pass along the original errno,
> not the new one.
>
> Or perhaps we're sharing a hallucination. :)
Well, set/getpriority(2), certainly can return "-1" and not be an error.
You would need to clear out errno before that call and check it on return.
This is where excpetions would be a great gain. It could also be used to
force programmers to check their system calls more closely. Oops, you didn't
handle excpetion foo? SIGBADPROGRAMMER.
--
David Cross | email: [EMAIL PROTECTED]
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science | Fax: 518.276.4033
I speak only for myself. | WinNT:Linux::Linux:FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
