sscanf always generates error condition

John Chambers jc at minya.UUCP
Fri May 17 14:20:55 AEST 1991


In article <1991May1.050122.21795 at athena.mit.edu>, jik at athena.mit.edu (Jonathan I. Kamens) writes:
> 
>   Second, technically speaking, the only time errno is relevant is when a
> system call fails.  This means that, in the strictest sense, it is not valid
> to use errno to find out what error occurred after a library function fails. 
> However, in cases where you know that the library function failed because of a
> failed system call, it's a good bet that errno will still contain the error
> return value from the system call, so it's usually OK to use it to determine
> what happened.

Well, gee, I've written lots of routines that do things like:
	if (f < 0 || f > maxfile) {
		errno = EBADF;
		return -1;
	}
I've recently seen a lot of suggestions, including the above, that I am
violating some rules that I've never seen documented.  It seems that the
naive programmer is highly likely to assume that such practices are not
only legal, but encouraged.  Now I find that some people think that errno
is not legal for me to use, even when it does the job quite elegantly.

So if I'm not allowed to mimic the system calls in such a case, what should
I do?  Should I set up a new global variable to hold the error code for each
routine, and make up my own error codes for each one?  Sure, I can do this,
but it doesn't seem like a very friendly thing to do to the poor suckers who
use my routines.

So what are the rules?  Is errno truly global, or is it supposed to be
private to libc?  Where is it documented and specified that I am forbidden
to use it in the obvious way, that I should have known about it?

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 
Work: 1-508-486-5475
Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc 



More information about the Comp.unix.programmer mailing list