> > 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: cro...@cs.rpi.edu 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
