Programming

Okay, it does not "create new file descriptors", it duplicates the parents file descriptors in the new child's process table, just like it copies the memory image.

A single process has no new file descriptors added to it's table as a result of calling fork or exec.

I think the original poster is concerned with the quantity of file descriptors open, so these difference in replies are semantic in nature - or at least that is how is appears to me.

If you "duplicate" file descriptors, someone might also say that new file descriptors are "created" because the number of file descriptors increases.

Well, but if a process is running out of fd's, it will never be due to the use of fork(). fork() creates a new process and the new process has its own set of newly created fd's. But the number of fd's in the original process does not grow. And while exec() can indeed close a fd if the close-on-exec bit was set, exec() does not have an "open-on-exec" concept. On the other hand, those dup2() do not look right. And dup2() can indeed add an fd to a process. We do not see how STDIN_FILENO and STDOUT_FILENO are defined so we can't be sure of what is happening. The return code from dup2 is being discarded so we don't know if the calls worked or not. I'm worried that this code might effectively be:
dup2(0,0);
dup2(1,1);
And it's not real clear what that would do. In a call like dup2(first, second), the man page says that since the second fd is open, it must be closed first. Or despite being all-caps, STDIN_FILENO and STDOUT_FILENO might actually be variables that get incremented somewhere. Also nowhere do I see anything about close-on-exec in the code... I don't understand why close-on-exec is even being mentioned here.