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