> I checked as follows I did printf("lowest fd = %d",fileno(tmpfile()));
> it prints 3
Which proves that file descriptor 3 was closed, so tmpfile() was able to
open it. This certainly implies that fd 0, 1, 2 (connected to stdin,
stdout, and stderr streams of stdio) are still open, contrary to your
statement that *all* of them are closed.
I know 0,1,2 are open (I opened it) no need to tell it specifically,
HOW DO YOU THINK I CAN PRINT SOME THING WITHOUT OPENING THIS
If file descriptor 3 is closed, but 4 is open, what does tmpfile()
do? Hint - tmpfile() ends up invoking open(), and the manpage for that says:
Given a pathname for a file, open() returns a file descriptor, a small,
non-negative integer for use in subsequent system calls (read(2),
write(2), lseek(2), fcntl(2), etc.). The file descriptor returned by a
successful call will be the lowest-numbered file descriptor not cur-
rently open for the process.
So.. explain why you think that "all files were closed"? We know that 0..2
were open, and we know nothing about 4..1023.
This doesn't look like a kernel bug, you may want to continue the discussion
on one of the various "beginning Linux C programming" lists.
On Tue, 06 Jun 2006 23:03:38 BST, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= said:
> > (Hint - what does that fp->_chain = stderr *really* do? ;)
> As it touches the innards of the FILE type, it invokes undefined
> behavior. Nothing that follows can be considered a bug.
Invoking undefined behavior is often considered a bug itself. And it's
certainly happening in userspace.. so there's a userspace bug. ;)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]