Re: [Libguestfs] [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe()

Or that glibc has taken special pains to make reliance on certain AS-unsafe functions (namely, malloc() and getenv()) "safer" in practice, despite permission from POSIX allowing glibc to throw caution to the wind and claim deadlocks to be the progammer's bug rather than glibc's. The fact that documentation does not match reality is indeed disheartening, but this may be a good time to open up bug requests to the documentation team(s) that can improve it for the next reader. Deadlock avoidance is one of the harder topics in computer science; I'm glad that glibc is going out of their way to make fork()/exec() work in more cases than promised by POSIX, but it also means a lot of programmers don't realize the complexities that glibc is solving on their behalf, and how their code may not be portable to a lesser libc.

>> https://www.austingroupbugs.net/view.php?id=1440 is where it came up >> in the Austin Group. Basically, having system("+s") be _required_ to >> invoke ["/path/to/sh", "-c", "+s"] is risky - "+s" is ambiguous >> between being the name of a real script and being a shell option