Re: New class of receive error

[Jason Thorpe <thorpej%me.com@localhost>]

On *NetBSD* it is, and that’s what matters.  I get that other OSs have this behavior, but another OS might play Towers of Hanoi, too, but NetBSD doesn’t and programs written to NetBSD’s historic behavior don’t expect it.

Never mind that ENOBUFS is kind of a weird error on a receive call... I’m not really objecting to the behavior, and I understand why it’s useful; I’m objecting to it being the default behavior because of the compatibility issue.

I have to think about this sort of thing at my Day Job all the time, so I’m particularly sensitive to it, I suppose.

-- thorpej
Sent from my iPhone.

> On May 13, 2018, at 10:01 AM, Roy Marples <roy%marples.name@localhost> wrote:
> 
>> On 13/05/2018 13:13, Jason Thorpe wrote:
>> If they get a new error code in a new situation, they don’t.
> 
> The situation is not new, nor should be unexpected - unless you're only looking at BSD man pages. Other OS's document ENOBUFS on recv calls.
> 
> 
>> -- thorpej
>> Sent from my iPhone.
>>>> On May 13, 2018, at 8:11 AM, Roy Marples <roy%marples.name@localhost> wrote:
>>>> 
>>>> On 13/05/2018 12:24, Jason Thorpe wrote:
>>>> I agree, this is unfortunate behavior that results in binary and source incompatibility.
>>> 
>>> ?
>>> 
>>> Old and new binaries work as before.