ABSOLUTELY NOT!
This is guaranteed behaviour of UNIX. You get file handles in order, or
you don't get them at all.
Sure, some library functions are allowed to use up file handles. But
most sure as hell are NOT.
> In general, open()
>can just return anything and about the only case where you can even
>think of ignoring its result is this:
> close(0); close(1); close(2);
> open("/dev/null", O_RDWR); dup(0); dup(0);
Which is quite common to do.
Imagine a server that starts up another process, which does exactly
something like the above: the _usual_ execve() case looks something like
pid = fork();
if (!pid) {
close(0);
close(1);
dup(pipe[0]); /* input pipe */
dup(pipe[1]); /* output pipe */
execve("child");
exit(1);
}
The above is absolutely _standard_ behaviour. It's required to work.
And btw, it's _still_ required to work even if there happens to be a
"malloc()" in between the close() and the dup() calls.
Trust me. You're arguing for clearly broken behaviour. malloc() and
friends MUST NOT open file descriptors. It _will_ break programs that
rely on traditional and documented features.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/