[1]: https://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c#n...
[2]: https://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c#n...
As usual, MUSL is secure at the cost of giving up usefulness. A 32-byte buffer might seem like a lot, but there are dozens of programs with a name longer than 31 bytes on my system. `dbus-update-activation-environment` is the most interesting (most others are gcc/binutils), and I know dbus in general uses syslog, though I haven't traced this particular entry point.
> As usual, MUSL is secure at the cost of giving up usefulness.
I would say 'Musl is deliberately simple at the cost of usefulness'. The simplicity lends itself to correctness and security.
Btw, since Musl does not implicitly construct log_ident from argv[0], program name is sort of irrelevant unless that program explicitly openlog()s with argv[0]. dbus-update-activation-environment does not appear to openlog or use syslog at all: https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/tools... Instead it prints error messages to stderr.
Maybe their implementation can't return negative, or only if the fmt string (constant, here) is invalid? I wouldn't count on it, especially of it being true forever. That's pretty sloppy code.
You can see the implementation here: https://git.musl-libc.org/cgit/musl/tree/src/stdio/vsnprintf... and https://git.musl-libc.org/cgit/musl/tree/src/stdio/vfprintf.... .
Not really a concern inside musl because those implementations are probably long gone and because it's calling its own snprintf() anyway.
> If you were trying to be portable and defensive you'd need to check for either error return.
Including defensive against future changes.
I'm sure thousands of bugs are being written every day because people don't check return values that "can't happen", because they know the code they call. Then 10-20 years later, someone changes that code they depend on, without violating the contract.
I encounter these kinds of bugs all the time. There's a simple way to avoid them: Check the damn return values, even if just with an assert.
The extra annoying ones are ones with a comment saying "Can't happen", that then does happen. The person who wrote that could have spent about the same number of characters simply handling the "can't happen".
We can't get away from Hyrum's Law, but we sure can try to minimize its impact.
I encounter bugs all the time that come from the fact that the caller knows the code they call, so they ignore the documented promises.
Let's all at least try to not invoke Hyrum's Law, even for code in the same project.