Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001493 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Comment Enhancement Request 2021-07-29 14:33 2024-06-11 09:07
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section 2.7
Page Number 2360
Line Number 75306
Interp Status ---
Final Accepted Text
Summary 0001493: move XCU 2.7 definition of "file descriptor" into XBD 3
Description XCU 2.7 Redirection has a definition of "file descriptor" that should be incorporated into the definition in XBD chapter 3 instead of being tucked away there.

Also, the definitions of standard error/input/output currently say they are streams, but they are also used in XCU (and perhaps elsewhere) to refer to file descriptors.
Desired Action On page 60 line 1783 section 3.166 File Descriptor, after:
A per-process unique, non-negative integer used to identify an open file for the purpose of file access.
append:
The values 0, 1, and 2 have special meaning and conventional uses, and are referred to as standard input, standard output, and standard error, respectively. Programs usually take their input from standard input, and write output on standard output. Diagnostic messages are usually written on standard error.

On page 92 line 2575 section 3.366 Standard Error, change:
An output stream usually intended to be used for diagnostic messages.
to:
In the context of file descriptors (see [xref to 3.166 File Descriptor]), file descriptor number 2.

In the context of standard I/O streams (see [xref to XSH 2.5]), an output stream usually intended to be used for diagnostic messages, and accessed using the global variable stderr.

Note: The file descriptor underlying stderr is initially 2, but it can be changed by freopen() to 0 or 1 (and implementations may have extensions that allow it to be changed to other numbers). Therefore, writing to the standard error stream does not always produce output on the standard error file descriptor.

On page 92 line 2577 section 3.367 Standard Input, change:
An input stream usually intended to be used for primary data input.
to:
In the context of file descriptors (see [xref to 3.166 File Descriptor]), file descriptor number 0.

In the context of standard I/O streams (see [xref to XSH 2.5]), an input stream usually intended to be used for primary data input, and accessed using the global variable stdin.

Note: The file descriptor underlying stdin is initially 0; this cannot change through the use of interfaces defined in this standard, but implementations may have extensions that allow it to be changed. Therefore, in conforming applications using extensions, reading from the standard input stream does not always obtain input from the standard input file descriptor.

On page 92 line 2579 section 3.368 Standard Output, change:
An output stream usually intended to be used for primary data output.
to:
In the context of file descriptors (see [xref to 3.166 File Descriptor]), file descriptor number 1.

In the context of standard I/O streams (see [xref to XSH 2.5]), an output stream usually intended to be used for primary data output, and accessed using the global variable stdout.

Note: The file descriptor underlying stdout is initially 1, but it can be changed by freopen() to 0 (and implementations may have extensions that allow it to be changed to other numbers). Therefore, writing to the standard output stream does not always produce output on the standard output file descriptor.

On page 2360 line 75294 section 2.7 Redirection, change:
The number n is an optional decimal number designating the file descriptor number; the application shall ensure it is delimited from any preceding text and immediately precede the redirection operator redir-op.
to:
The number n is an optional one or more digit decimal number designating the file descriptor number; the application shall ensure it is delimited from any preceding text and immediately precedes the redirection operator redir-op (with no intervening <blank> characters allowed).

On page 2360 line 75304 section 2.7 Redirection, change:
Open files are represented by decimal numbers starting with zero. The largest possible value is implementation-defined; however, all implementations shall support at least 0 to 9, inclusive, for use by the application. These numbers are called "file descriptors". The values 0, 1, and 2 have special meaning and conventional uses and are implied by certain redirection operations; they are referred to as standard input, standard output, and standard error, respectively. Programs usually take their input from standard input, and write output on standard output. Error messages are usually written on standard error. The redirection operators can be preceded by one or more digits (with no intervening <blank> characters allowed) to designate the file descriptor number.
to:
The largest file descriptor number supported in shell redirections is implementation-defined; however, all implementations shall support at least 0 to 9, inclusive, for use by the application.
Tags tc3-2008
Attached Files

- Relationships

-  Notes
(0005422)
kre (reporter)
2021-07-29 16:49

 I have no problem with this change in general, though there are a
couple of wording changes (just cleanups) I'll suggest in some later
note if no-one else gets there first, but this part:

   The file descriptor underlying stdin is initially 0; this cannot
   change through the use of interfaces defined in this standard,

(and the similar limitations expresseed for stdout and stderr) looks
to be simply wrong to me. I'm also not sure there's any need to
actually make this point, even if it were true.

But consider

     close(fileno(stdin));
     fd = open("/dev/null", 0);
     freopen("/my/file", "r", stdin);

(use fdopen() instead of open() if you prefer, but not fclose() as
any use of any stream after it has been fclose'd is undefined, as its
data struct may have been discarded).

I'm not sure what file descriptor you expect freopen() to assign in
that case (assuming the open of /my/file succeeds, etc, of course),
but it isn't usually going to be 0, and this is using only interfaces
defined by the standard, I believe.

Note that freopen() specifically says:

    If pathname is not a null pointer, freopen() shall close any file
    descriptor associated with stream. Failure to close the file descriptor
    successfully shall be ignored.

That is, freopen() is defined to work properly if the file descriptor has
already been closed (some systems may have other reasons for the close failing,
allowing for a different fd to be returned from the open, but that would be
using something beyond the standard interfaces I think).
(0005424)
geoffclare (manager)
2021-07-30 08:53

 Re: Note: 0005422 Given the code:

     close(fileno(stdin));
     fd = open("/dev/null", O_RDONLY);
     freopen("/my/file", "r", stdin);

and assuming fileno(stdin) is 0 (which is the case the proposed text is referring to), freopen() will close fd 0 and then open "/my/file" on fd 0. The fd number underlying stdin will not change.

I included the notes for standard error and standard output as I thought it worth pointing out that "standard output" can refer to two different files depending on whether you mean the file descriptor or the stream. I have encountered people in the past who thought they were always the same, i.e. that freopen() preserved the fd number (if possible) instead of opening the lowest available. I included a similar note for standard input for consistency.
(0005426)
kre (reporter)
2021-07-30 15:05

 Re Note: 0005424 -- yes, of course, there's no way to get rid of the 0 from
fileno(stdin), so the close() in freopen() always does close(0) so the open
the succeeds it will always return 0.

Still not sure it is worth the notes though, if anything more complex than
to note that there's no guarantee that fileno(stdXX) is the sand as standard
XXput (or err).

Saying what values they must have will just lead to people (as I did) trying
to demonstrate that it isn't necessarily correct.

- Issue History
Date Modified Username Field Change
2021-07-29 14:33 geoffclare New Issue
2021-07-29 14:33 geoffclare Name => Geoff Clare
2021-07-29 14:33 geoffclare Organization => The Open Group
2021-07-29 14:33 geoffclare Section => 2.7
2021-07-29 14:33 geoffclare Page Number => 2360
2021-07-29 14:33 geoffclare Line Number => 75306
2021-07-29 14:33 geoffclare Interp Status => ---
2021-07-29 16:49 kre Note Added: 0005422
2021-07-30 08:53 geoffclare Note Added: 0005424
2021-07-30 15:05 kre Note Added: 0005426
2021-11-18 17:30 Don Cragun Status New => Resolved
2021-11-18 17:30 Don Cragun Resolution Open => Accepted
2021-11-18 17:30 Don Cragun Tag Attached: tc3-2008
2021-12-13 15:28 geoffclare Status Resolved => Applied
2024-06-11 09:07 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker