Re: Why do sendmmsg and recvmmsg take unsigned int flags?

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Fri, Jun 12, 2026 at 06:08:05 -0400, Greg Troxel wrote:

>   This is a non-POSIX API.  So we're not wrong, just different.

It was committed with

  Add {send,recv}mmsg from Linux

and "from Linux" in practical terms means "linux/glibc", b/c that's
what "linux software" primarily targets.  So glibc sets the de-facto
standard here and it has `int flags`.


>   Arguably unsigned int, as a type in a new API, is the better choice,
>   although one can also argue that as it's a derived API from sendmsg,
>   it's more important to fix that.

Exactly.  This is not a completely new API, but an extension of
send&c, so consistent type for `flags` is just good hygiene (and
that's probably the reason glibc chose to match existing API and not
the raw syscall).


>   I wonder if you are able to see if they are going to change Linux,
>   change glibc, change musl etc.  I would be inclined to wait until that
>   plays out.

I think it's pretty much inconceivable that glibc will change that.

https://www.openwall.com/lists/musl/2026/06/11/2 - for musl Rich is
open to aligning with glibc:

| I'm pretty sure this was unintentional, perhaps just matching
| documentation of the raw syscall. We should look at whether it makes
| sense to align it with other implementations.


>   "Fix" is messy, because we have a longstanding published API.  We
>   could just flip the type to int in the syscall code and the header,
>   and probably almost zero code will need to change, as the typical
>   thing is to pass 0 or MSG_FOO, not to have set things up in a
>   variable.
> 
>   I don't see that we have any backwards-compat API scheme like we do
>   for versioned syscalls.

I don't think changing signedness of flags affects ABI.  At API level,
passing (or'ed) literals should DTRT with both.  If a variable is
involved, -Wsign-conversion (not even in -Wextra, iirc) will indeed
complain.


> On balance I see this as not a real prblem and am inclined to wait for
> the Linux world to settle out to see if there is a larger consensus
> before making changes.

Yes, there's no urgency.


-uwe