Re: [PATCH V2] Fix return value from fstat calls

From
Jes Sorensen <hidden>
Date
2021-08-13 19:19:50
Reply to
Tkaczyk, Mariusz, 2021-08-13
On 8/13/21 3:45 AM, Tkaczyk, Mariusz wrote:
On 13.08.2021 09:19, NeilBrown wrote:
quoted
On Fri, 13 Aug 2021, Tkaczyk, Mariusz wrote:
quoted
quoted
Error handling that is buggy, or that is hard to maintain is not better
than nothing.  If I can't guarantee that we never pass a bad file
descriptor, then you cannot guarantee that the error handling has no
bugs.   Less code generally means less bugs.

Any attempt to try to handle an error that should not be able to happen
other than crashing is fairly pointless - you cannot guess the real
cause, so you cannot know how to repair.  Just printing a message and
continuing could be as bad as not checking the error.
As error handling, I meant any error verification. It doesn't indicate
that we should return status and end gracefully. exit() is elegant
solution in this case, totally agree.
Just catching up here on this.

I totally agree that we need to work on catching errors and exiting
properly. It will also help returning error codes from this more silly
error handling cases to keep the certification people happy. This is a
much bigger job than just these checks though.

I don't think Nigel's patch is really harmful, but I don't think it adds
any real value either, without returning the actual error codes from
fstat and parsing them op the stack properly.

Jes

Thread (5 messages) 5 messages, 3 authors, last reply 2021-08-13
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help