[Adding libc-alpha@ for some doubts] Hi! On Sun, May 26, 2024 at 01:27:43PM GMT, Alejandro Colomar wrote: > On Sun, May 26, 2024 at 01:07:24PM GMT, Alejandro Colomar wrote: > > I'm considering making sashimi of prctl(2), similar to what I did > > recently to proc(5). Another precedent is in ioctl(2). I'll call the pages with names such as PR_CAP_AMBIENT(2const) and PR_CAP_AMBIENT_RAISE(2const). While doing that, I changed the prototypes in the SYNOPSIS to things like int prctl(PR_CAP_AMBIENT, unsigned long op, ...); and int prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, unsigned long cap, 0, 0); Which makes me wonder. glibc implements prctl(2) as a variadic function, so those 0s are actually of type (and more importantly of width) 'int'. This means a user passing 0 is leaving some parameters uninitialized. From what I can see, glibc does no magic to set unspecified parameters to 0, so this means passing '0' results in Undefined Behavior. I guess I should document these as 0L in the SYNOPSIS. int prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, unsigned long cap, 0L, 0L); All of the software I've seen out there using prctl(2) either pass 0 (as the manual page had been suggesting), such as in shadow: if (prctl(PR_SET_KEEPCAPS, 1, 0, 0, 0) < 0) { or don't pass anything at all (coreutils does this): if (prctl (PR_SET_DUMPABLE, 0) == 0) Am I missing something or are all of those calls buggy? Some prctl(2) calls report EINVAL when the unused arguments are nonzero, while others simply ignore it, so maybe I can document the ones ignoring the unused arguments as shorter calls: int prctl(PR_SET_DUMPABLE, unsigned long dumpable); And document the ones that report errors as using 0L: int prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, unsigned long cap, 0, 0); (BTW, util-linux seems to have this one wrong:) && prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, cap, 0, 0) < 0) What do you think about this? Have a lovely day! Alex --