Benjamin Saunders

One hazard with a general-purpose allocator we should be wary of is difficulty predicting total memory use, particularly as its wasted memory is inaccessible to other parts of the user's...

I'm not sure exposing more errors is useful. The motivation behind the current behavior is that UDP network errors are almost invariably one of two cases: those that can be...

> permanent (until network connections change at which point we make a new socket). "Permanent until it changes" isn't very permanent. Further, if your socket is bound to the wildcard...

> There is. On MacOS, a socket bound to the wildcard address will not be able to use newly attached interfaces. What, really? Is that documented anywhere? That makes it...

> Communicating such a change can easily be done by breaking / deprecating the API purposely and thus causing compile errors for all existing users. This addresses my concern, though...

To avoid unpleasant surprises for downstream, I think should introduce a new function rather than drastically changing the semantics of the current one. Open to other ideas, though.

Sure. And presumably a recv version, too?

> What can fail in receive that we currently don't expose? Actually, looks like we don't suppress recv errors at all, so probably no changes needed there.

That's a weird one. Can we push for a fix upstream? Bearing mind that we'll need to work around the issue on older devices anyway.

> By upstream, do you mean Android? Right. > Android 13 is from 2022 so I'm assuming they'll be reluctant to put in fixes like this. I couldn't guess either...