Re: New class of receive error

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

    Date:        Tue, 15 May 2018 20:45:20 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <a5b1981d-789d-17c7-bab5-c07afb6c24a7%marples.name@localhost>

  | On 13/05/2018 13:13, Jason Thorpe wrote:
  | > If they get a new error code in a new situation, they donâ??t.
  |
  | I've thought about this for some time, and respectfully I disagree.

If I am not mistaken, was not the issue in the PR that started this
discussion (53247) exactly that dhcpcd did not correctly handle this
new error code?

Isn't that, of itself, evidence that Jason is correct?

  | A new error code (remember, it's just errno being set not the return 
  | value) is no different from a new RTM_* message being added and no-one 
  | has claimed thus far that breaks binary or source compatibility.

No, but that's because getting unknown message types has always been
something that applications have expected - they explicitly look for the
ones they want to process, and ignore all others.

If appliucations explicitly looked for errno values they understand, and 
ignored all others, then the analogy might be germane, but they don't.

In fact, as I said in an earlier message, unless the application deliberately
enabled non-blocking mode, or is catching signals and continuing, none of
the errors from recv() were things that an application would normally
expect to continue from - if any of the previously defined errors occurred
(other than in those two cases) it is entirely reaosnable for the application
to simply log an error and quit.   That's not appropriate handling for your
new error code, rather an app that has nothing better to do with it should
simply ignore it and retry the recv*().

kre

ps: has the fix for 53247 (the real fix, not the buffer size increases) been
committed to -current yet?   If not, why?  If it has, has a pullup for -8 been
requested yet?