Hi,

Nan Xiao wrote on Fri, Apr 20, 2018 at 10:11:55PM +0800:
> Ingo Schwarze wrote:
 
>> No.  Read the manual page and /sys/kern/kern_time.c :
>>
>> With a valid clock id and a valid address, this function
>> cannot fail, so you are just adding dead code.  Worse,
>> you are making future auditors wonder what the heck is
>> going on here.

> Sorry, I can't find the above words from manual
> (https://man.openbsd.org/clock_gettime.2).

It is documented in the usual way:  RETURN VALUES says that
errno is set on failure, and ERRORS only lists EINVAL and
EFAULT.

That said, i admit that many ERRORS sections are incomplete, and
it would cause huge effort to improve (and maintain) them.  That's
why you have to inspect the kernel or library code when in doubt,
and why i referenced the implementation of the syscall, which is
short and simple in this case.

There are many functions that return success or failure, but where
nothing is wrong with ignoring the return value in many situations.
The most famous example is probably close(2); it is very rarely
useful to check the return value.

So, there are three classes of functions:

 (1) Those that almost never need return value checks,
     like close(2).  Just call them as if they were void,
     except in the odd case where you do need to check
     for some unusual reason.
 (2) Those where ignoring the return value is often fine,
     like printf(3) and clock_gettime(2).  Call them
     as if they were void or check, depending on the
     situation, and on style.
 (3) Those where ignoring the return value is usually a
     bug, like strlcat(3).  In the unusual case that you
     do want to ignore failure, add an explicit (void) cast,
     and if the reason is non-obvious, add a comment
     explaining why failure should be ignored in this
     particular case.

Distinguishing these classes needs a bit of experience, they
are not documented.  Such experience can be gained by reading code.
Try, for example,

   $ grep -RF -C20 clock_gettime /usr/src/usr.sbin | less

There are also edge cases where it's a matter of taste and style -
not everything is as clear as that "(void)close(fd)" is stupid and
that unchecked strlcat(3) raises a red flag with auditors.  It
appears some code authors do check clock_gettime(2) return values
even if there is no particular reason for it, for example, but i
see no reason to add or remove such checks unless someone is actively
working on the code in other respects.  The code is correct with
or without.

Yours,
  Ingo

Reply via email to