Date: Sat, 30 Dec 2017 07:44:57 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Eugene Grosbein <eugen@grosbein.net> Cc: Ian Lepore <ian@freebsd.org>, Yuri <yuri@rawbw.com>, Freebsd hackers list <freebsd-hackers@freebsd.org> Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? Message-ID: <201712301544.vBUFivES076428@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <5A47A504.1030901@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Charset windows-1252 unsupported, converting... ] > 30.12.2017 21:06, Rodney W. Grimes wrote: > > >> Of course, there are cases when that's irrelevant, f.e. closing temporary file > >> that is no more needed and being unlinked anyway. > > > > No error on close should be treated as irreleveant, they signify something > > has gone wrong and itis best to inform the user and let the user decide > > if this is irrelevant or not. > > > > Code that does not test return codes from EVERY single thing that can > > return an error should be taken out back shown the danish axe, clean it > > up or get it out of our tree! > > An application checks for error code after writing to stderr to report an error > and finds it failed too; and what should be done then? :-) One should do the right thing, you know that this is a case of the output to stderr failed, and that it would not be right to try to output another error, but probably just call exit with a non zero value so that the caller may be able to do something with that data. Your trying to over complicate what is a very simple rule, if a status can be returned, one should check it and try to do the best thing possible. Or maybe we should just turn off the compiler warning that flags this? > > > One should never code to the "normal" conditions situation, it makes for > > code that does not work well when the "abnormal" conditions arrise. > > > > In real world, there are cases of temporary errors like some transient > system resource shortage; application's own short timeout on close() > because of NFS-server responding slow due to short network malfunction; > temporary DNS failure etc. Not every such case deserves user attention > as system must have some level of self-healing (retry, disregard etc.) And silently ignoring these transient conditons is right in what way? Weeee.. lets silently not tell the user that his data may not be there cause we had a transient error condition? > > > I would argue that in the above sample of "closing and unlinking" it > > would actually be better to exit if the close failed possibly leaving > > behind the evidence of why/what failed rather than blindling forging > > ahead and potentially destroying the evidecnce by unlinking the file. > > > > If someone wants to go chasing after "failure to check exit codes" please > > begin with /etc/rc.d/*, these scripts are so full of it I laugh every > > time I see a system come up multiuser after 10+ errors have happendend > > in them. > > Mostly it is NOT better to halt and sit instead of proceeding to multiuser anyway. >From a security standpooint it IS better to halt and sit instead, as some important security aspect may not be correct now because we blazed ahead ignoring errors!!!!! It is also senseless to go forward if /usr is missing cause of some mess up, as then there well be no /usr/lib/getty and most likely no one is going to be able to login anyway, necessatating the need to do either an ACPI poweroff event, ctl-alt-del event, or god forbit hard power down, followed by a reboot to single user to fix the issues almost always leaving you with dirty file systems and other not so nice things. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201712301544.vBUFivES076428>