Valery Ushakov <[email protected]> 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 <[email protected]> > Subject: Why do sendmmsg and recvmmsg take unsigned int flags? > To: [email protected] > 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.
