|Anonymous | Login||2022-01-16 19:46 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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||2021-12-13 15:28|
|Organization||The Open Group|
|Final Accepted Text|
|Summary||0001493: move XCU 2.7 definition of "file descriptor" into XBD 3|
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.
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.
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.
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.
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.
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.
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).
Re: Note: 0005422 Given the code:
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.
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.
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|