The signature of "execv" | "execve" | "execvp" | "fexecve" is incorrect

[gnzlbg]

The type of argv is *const *const c_char but should be *const *mut c_char. With the current incorrect signatures, libc-test fails for these APIs, but this does not surface because these tests are skipped. With the fixed signatures, all tests pass.

AFAICT, this affects all unix targets.

[gnzlbg]

@asomers it would be better to start fixing these in freebsd

@semarie it would be good to know if their signature is also incorrect in openbsd and netbsd (e.g. by trying to remove their "skip" in libc-test/build.rs since we can't check that in CI.

I'll try to roll in a fix for Android.

After that is done, we can fix these on Linux, and do an update upstream, crater run, etc.

[asomers]

Why do you think it would be best to start with FreeBSD? It seems that the same problem exists on Linux.

[gnzlbg]

We could try rolling this change for all targets at once as well. These APIs are available on all tier-1 targets, so I just thought that it might be "safer" to try to roll the change for less used targets first, and if there aren't any problems, only then attempt that for the tier-1 targets.

AFAICT libstd does not use these APIs, so it is unclear to me how many people are using them (is anybody using them at all?) and how (e.g. whether changing the mutability of that pointer would be a breaking change for them or not).

[asomers]

Well, Nix uses libc::execve. And the proposed change will break Nix. In fact, I think the error here is not in libc. The error is in execve's signature as mandated by POSIX. POSIX says "The argv[] and envp[] arrays of pointers and the strings to which those arrays point shall not be modified by a call to one of the exec functions, except as a consequence of replacing the process image.", yet it still specifies a non-const array for argv. That's a bug. It's probably a very old bug, dating to the days before C had a const keyword. But given that "shall not be modified" requirement, I think that it's safe (and preferable) for libc to use a *const *const c_char argument.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html

[gnzlbg]

Doesn't the "except as a consequence of replacing the process image." imply that those can actually be modified ? (EDIT: I thought replacing the process image was the main point of calling these functions).

[asomers]

I interpret that as meaning that they may be modified in the child's image, but not in the parent's image. The constness of the pointer only matters from the perspective of the parent.

[gnzlbg]

Makes sense. The question still is, why should we do something different than C here ? If the C headers have a bug, then that would be a good enough reason, but I am not sure if that's the case here.

[semarie]

Regarding openbsd, the signature is incorrect.

correct definitions for openbsd are:

• pub fn execvpe(file: *const ::c_char, argv: *const *mut ::c_char, envp: *const *mut ::c_char) -> ::c_int;
• pub fn execv(prog: *const c_char, argv: *const *mut c_char) -> ::c_int;
• pub fn execve(prog: *const c_char, argv: *const *mut c_char, envp: *const *mut c_char)
• pub fn execvp(c: *const c_char, argv: *const *mut c_char) -> ::c_int;

[gnzlbg]

@semarie thanks, yes that is the signature that POSIX prescribes so basically all targets right now have this "issue". ABI-wise, a pointer is a pointer, and whether it is const or mut doesn't matter much.

[asomers]

If we were writing libc from scratch, then we should probably just copy the C headers and require users to deal with the wrong constness. However, "fixing" libc at this point would break released versions of crates like Nix. I don't think the payoff is worth the pain.