Re: new errno ?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 6 Jul 2018 13:46:42 -0600
    From:        Warner Losh <imp%bsdimp.com@localhost>
    Message-ID:  <CANCZdfoAd2LWnsMFmUaTMCe8URxv0T75H4bMshFVr2kt-CBWoA%mail.gmail.com@localhost>


  | Poul-Henning added it to differentiate between potentially valid but not in
  | this combo (EINVAL or EFAULT) and args that are clearly programming errors
  | (EDOOFUS), but in code that couldn't just panic.

I fail to understand the logic behind that.   What's more I think from the 
original (FreeBSD) thread, it is incorrect.,  That is, the argument was not
that the code could not panic (I find it very hard to even conceive of the
possibility of a case where it is possible to return an error to the user, but
a panic (in kernel) or abort() (in userlevel code) is not possible) but rather
that it was possible to not panic, and so that is the path that should be
taken.

Sorry, but that is just brain dead.

The situation where an internal programming inconsistency has been
detected is the one (perhaps the only) place where a panic (or abort)
is the right solution.   Then it happens, once, somewhere, someone works
out what caused it, fixes it, and it never happens again.

That's quite different than having perror() report "Programming Error"
which is likely to cause whatever user level programmer wrote the
code that got the error to scratch his.her head, try to figout out what
they did wrong, and either find a workaround (and believe they are
fixing their bug) or just give up ... and the error persists.

There's no question byt that unix does (always has) panic/crash far
too often, for things which would be better recovered from, or  reported
as wrrors to the user (various I/O errors, unplugging drives half way
through I/O, bad packet data ... ) which it would be really good to fix
(but much of that is HARD, and I am definitely not volunteering, I could
have worked on that kind of thing any time over the past 40+ years, and
never did ...)

But this one is different, this is "the system is screwed internally" (rof
whatever the "system" is in question) - simply aborting until the problem
gets fixed is the right solution.

kre