fileno(stdin) versus STDIN_FILENO and friends
Eric Norum
wenorum at lbl.gov
Fri Mar 11 20:26:46 UTC 2011
The document at http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html implies that they really are supposed to be constants:
The following symbolic constants shall be defined for file streams:
STDERR_FILENO
File number of stderr; 2.
STDIN_FILENO
File number of stdin; 0.
STDOUT_FILENO
File number of stdout; 1.
but I agree that that is rather counterintuitive.
On Mar 11, 2011, at 12:21 PM, Peter Dufault wrote:
> Shouldn't STDOUT_FILENO etc always be valid, regardless of thread?
>
> Consider this code snippet installed in the RTEMS shell as "filenos":
> ===
> static int
> filenos_cmd(int argc, char **argv)
> {
> int stdin_fileno = fileno(stdin),
> stdout_fileno = fileno(stdout),
> stderr_fileno = fileno(stderr);
>
> fprintf(stderr,
> "fileno(stdin), STDIN_FILENO: %d %d\n"
> "fileno(stdout), STDOUT_FILENO: %d %d\n"
> "fileno(stderr), STDERR_FILENO: %d %d\n",
> stdin_fileno, STDIN_FILENO,
> stdout_fileno, STDOUT_FILENO,
> stderr_fileno, STDERR_FILENO);
>
> fprintf(stderr, "- %s\n",
> (stdin_fileno == STDIN_FILENO &&
> stdout_fileno == STDOUT_FILENO &&
> stderr_fileno == STDERR_FILENO) ? "OK" : "BAD");
>
> return 0;
> }
> ====
>
> Called from the console:
>
> [/] # filenos
> fileno(stdin), STDIN_FILENO: 0 0
> fileno(stdout), STDOUT_FILENO: 1 1
> fileno(stderr), STDERR_FILENO: 2 2
> - OK
> [/] #
>
> Called via telnet:
>
> [/] # filenos
> fileno(stdin), STDIN_FILENO: 7 0
> fileno(stdout), STDOUT_FILENO: 8 1
> fileno(stderr), STDERR_FILENO: 9 2
> - BAD
> [/] #
>
> Shouldn't the macros reference something that changes with the thread context to appropriate file descriptors without forcing reference to <stdio.h>?
>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc. Software and System Engineering
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
--
Eric Norum
wenorum at lbl.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110311/0a7d6f09/attachment-0001.html>
More information about the users
mailing list