I'm pretty sure popen is just a wrapper around this stuff. It's basically,
pipe: get two fds connected by a pipe
fork: create a child process
dup2: move the read fd of the pipe to 0 (stdin) in the new process
exec: run the program in the child process
There's some cleanup but that's the gist - popen isn't a syscall (or reasonably close to one), so must necessarily rely on other stuff to get its work done where it actually interfaces with the kernel.
That makes perfect sense. It's the fork+exec that makes it dangerous (e.g. in the CGI context). This is something I've been wondering about and you have just provided a jolt of clarity. Many thanks, again.
pipe: get two fds connected by a pipe
fork: create a child process
dup2: move the read fd of the pipe to 0 (stdin) in the new process
exec: run the program in the child process
There's some cleanup but that's the gist - popen isn't a syscall (or reasonably close to one), so must necessarily rely on other stuff to get its work done where it actually interfaces with the kernel.