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

[Greg Troxel <gdt%lexort.com@localhost>]

Valery Ushakov <uwe%stderr.spb.ru@localhost> writes:

> Saw this on the musl mailing list.
>
> We also seem to have `unsigned int flags` since day one.  Note that
> `flags` is the same as in send/recv &co, where it's `int flags`.
>
> Should we fix this?

My immediate reaction is to urge caution, as it's really not clear who's
right and between "day one" etc. I assumed this was from 4.2BSD or
earlier.

But then I saw sendmmsg, with an extra m, and realized this was not "day
one" API, and you mean from when it was added, not the origin of NetBSD.

The first thing to do is to check POSIX.
sendmsg is defined:

  https://pubs.opengroup.org/onlinepubs/9799919799/functions/sendmsg.html

as taking "int flags".   I suspect this is just how it was done in early
BSD, even thought unsigned makes more sense for flags.

Not surprisingly sendmmsg is not defined.

> From: Alyssa Ross <hi%alyssa.is@localhost>
> Subject: Why do sendmmsg and recvmmsg take unsigned int flags?
> To: musl%lists.openwall.com@localhost
> Date: Thu, 11 Jun 2026 18:30:18 +0200 (17 hours, 19 minutes, 11 seconds ago)
>
> sendmmsg and recvmmsg are declared in musl as follows:
>
> int sendmmsg (int, struct mmsghdr *, unsigned int, unsigned int);
> int recvmmsg (int, struct mmsghdr *, unsigned int, unsigned int, struct timespec *);
>
> Glibc declares the fourth parameter (flags) as int, as does FreeBSD.
> The syscall definition in Linux is unsigned int, but I'd have expected
> compatibility with other implementations to outweigh matching the
> syscall.

Sounds like Linux has some consistency troubles, as it seems obvious
that syscalls and their libc veneers should match.  (libc should match
POSIX, and syscalls should match that too, I mean.)   But that's not our
problem to fix.

> Was this an intentional decision?  Should it stay this way?
>
> (I encountered this due to a test that wraps libc's sendmmsg[1])
>
> [1]: https://gitlab.freedesktop.org/libnice/libnice/-/blob/master/tests/instrument-send.c#L193-218
>
> ----------

I see in kern/uipc_syscalls.c that flags is declared unnsigned in the
interface and coppied into an unsigned.  But also that with masking it
never matters.   And further that flags is just passed to
do_sys_sendmsg, which takes "int".

As to what to do,

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

  NetBSD, musl and the Linux kernel are unsigned int.   FreeBSD and glibc are int.

  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.

    Having read the code, I think  the right call would have been to
    match the type of flags in sendmsg.

  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.

  "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.


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.