Re: [groff] [off-topic] Reliable use of errno

[Ingo Schwarze]

Hi,

Carsten Kunze wrote on Sun, Aug 19, 2018 at 02:32:49PM +0200:

> Many system calls (e.g. close(2),
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html)
> return 0 on success and -1 on error and set errno.
> 
> My understanding is that errno is only reliably set when the system
> call returns -1, not for < -1 nor for > 0,

What usually matters more than knowing whether errno has been set or
not is detecting failure - even though close(2) is the most typical
example of a system call where checking the return value / checking
for failure is almost never useful, and simply ignoring both the
return value and errno is what you should do in most cases.

> so I do only check the error condition with "if (close(fd) == -1)"
> ignoring all other values.

That is best practice.  You should assume the system behaves as specified
and test for the exact values that can be returned according to the
specification.  If the system violates the specification, well, then
you are in unspecified territory anyway and your program cannot run
reliably either way.

> Some are testing for "< 0" but would it not be consequent
> for them to check for "!= 0"?

Neither would be best practice, but if the system behaves according
to specification, it doesn't make a difference in practice - it
merely looks confusing to a code auditor.

> So when can I rely on errno to be set, for -1, for "< 0" or for "!= 0"?

You can rely on the function to return -1 on failure and 0 on
success, and you can rely on errno being set on failure.
Other return values can never happen unless there is a severe
bug in the kernel or in the C library.

> In case of library functions (e.g. fclose(3),
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/fclose.html)
> we have a similar situation with the return values 0 and EOF.
> 
> I did test for errors with "if (fclose(fh) == EOF)",

That is best practice.

> others are testing for "!= 0".

See above; not best practice, but no real difference in practice.

> When can I rely here for errno to be set, only in case of EOF
> or als for "!= 0"?

Values other than 0 or EOF cannot happen, and EOF is specified to
be < 0, so != 0 is correct, too, just slightly confusing.

Finally, note that

 * bugs with errno (not being set even though it should, being set
   to the wrong code, or being clobbered even though the function
   succeeded) are relatively common in C libraries, so the
   only purposes errno should be used for are
    - reporting the (probable) cause of failure to the user
    - (trying to) distinguish different causes of failure
      for taking appropriate action
    - detecting failure for those severely ill-designed
      functions where the return value is unhelpful, most
      notably strtol(3) - needs very careful coding, though

 * not all functions adhere to the 0/-1 scheme to report success
   or failure, allways check the spec.  Behaviour of some is
   implementation-dependent in some respects, most notably in
   the printf(3) family.

Yours,
  Ingo