Comments on Interpretations Austin-288 Page 1 of 1 Submitted by Andrew Josey, The Open Group. March 18, 2006 (updated April 3 2006) This document records comments received on interpretations. This will be discussed at the next teleconference. This document will be amended as further comments come in that need discussion. Editorial comments will have been addressed by the editor and not added to this document AI-047 Topic: XBD 8.1:environment variable definition In Austin-047 we have: The following will preserve these environment variables as well as preserve the PATH for conforming utilities: env -i $(getconf V6_ENV) $(getconf PATH) command Stephane Chazelas pointed out that this should be: env -i $(getconf V6_ENV) PATH="$(getconf PATH)" command and that there is an issue about how the expansion of $(getconf V6_ENV) is affected by IFS and file globbing. We should probably add something about the behaviour being undefined if IFS contains characters other than , and or if one of those is missing from IFS, and restrict the variable values output from getconf V6_ENV in some way (probably either forbid *, ? and [ characters, or restrict the allowed characters to the portable filename character set). AI-053 Topic: asctime() tm_year gt 9999 The justification for this rewording is that, as I mentioned in , the current draft interpretation is incompatible with C99, and therefore it is also incompatible with page 123 lines 4484-4486, which state that the asctime() functionality is aligned with the C standard. One other point that I just remembered: ctime() and ctime_r() suffer from the same problem that asctime() and asctime_r() suffer from, and their descriptions should be altered similarly. The proposed rewording is to remove the entire Notes to the Editor in the draft interpretation, and replace it with the following: page 123 after line 4508, add: However, the behavior is undefined if timeptr->tm_wday or timeptr->tm_mon are not within the normal ranges as defined in , or if timeptr->tm_year exceeds INT_MAX - 1900, or if the above algorithm would attempt to generate more than 26 bytes of output (including the terminating null). page 123 line 4515, change from: (of the same form as that returned by asctime()) to: (of the same form as that returned by asctime(), and with the same undefined behavior when input or output is out of range) page 124 lines 4531-4533, remove: This function is included for compatibility with older implementations, and does not support localized date and time formats. Applications should use strftime() to achieve maximum portability. page 124 after line 4535 add: These functions are included only for compatibility with older implementations. They have undefined behavior if the resulting string would be too long, so the use of these functions should be discouraged. On implementations that do not detect output string length overflow, it is possible to overflow the output buffers in such a way as to cause applications to fail, or possible system security violations. Also, these functions do not support localized date and time formats. To avoid these problems, applications should use strftime() to generate strings from broken-down times. page 248 lines 190-192, remove: The ctime() function is included for compatibility with older implementations, and does not support localized date and time formats. Applications should use the strftime() function to achieve maximum portability. page 248 after line 8194 add the following text, which is identical to the proposed text added after page 124 line 4535: These functions are included only for compatibility with older implementations. They have undefined behavior if the resulting string would be too long, so the use of these functions should be discouraged. On implementations that do not detect output string length overflow, it is possible to overflow the output buffers in such a way as to cause applications to fail, or possible system security violations. Also, these functions do not support localized date and time formats. To avoid these problems, applications should use strftime() to generate strings from broken-down times. ------------------------------------------------------------ AI-079 Topic: mmap() shared synchronization primitive The new paragraph in the Notes to the Editor isn't entirely clear: Add a new paragraph after line 25808: The state of synchronization objects such as mutexes, semaphores, barriers, conditional variables placed in shared memory mapped with MAP_SHARED becomes undefined when the region containing the synchronization object is unmapped By "is unmapped", is it meant to say "a mapping is removed", or "the last mapping is removed"? ------------------------------------------------------------ AI-084 Topic: sigaction SA_RESTART In the Notes to the Editor there is: On line 42554 insert before the sentence commencing "If the flag is..." If an interruptible function which uses a timeout is restarted, the behavior and duration of the timeout following the restart is set to an unspecified value that does not exceed the original timeout value. The new text doesn't make sense. Perhaps it just needs "behavior and" to be removed. ------------------------------------------------------------ AI-092 Topic: sort, Utility Syntax Guideline 13 This proposes a change to the standard that (if I understand it correctly) contradicts common practice. Here's what I'm objecting to: After XBD line 7240, add "Where a utility described in the Shell and Utilities volume of IEEE Std 1003.1-2001 as conforming to these guidelines accepts the operand - to mean standard input or output, this usage shall be explained in the OPERANDS section." First, the "shall" is a constraint on the standard, which isn't proper wording. "Shall" applies to implementations, or to applications or users, not to the standard itself. Second, if I understand the proposed change correctly, it would render several implementations nonconforming. It would mean, for example, that the command "cksum -" must attempt to read a file named "-", and "cksum -" cannot attempt to read standard input. But common practice (e.g., Solaris 10, GNU coreutils 5.94) is for "cksum -" to read standard input. Similar issues affect "od" and "tail" (for both Solaris and coreutils) and "expand", "fold", "head", "nl", "tee", "touch", "unexpand", and "wc" (coreutils). In the above lists, I haven't checked all the utilities specified by POSIX; only those implemented by coreutils. Nor have I checked platforms other than Solaris or GNU. I suspect other utilities and platforms are affected, though. One way to address this issue would be to clean up the "shall"-related wording a bit, and to modify the pages for "cksum", "od", "tail", "expand", etc. But this is an error-prone process. I suggest a simpler fix. Omit the proposed change quoted above, and replace it with this: After XBD line 7240, add: Where a utility described in the Shell and Utilities volume of IEEE Std 1003.1-2001 as conforming to these guidelines is required to accept the operand '-' to mean standard input or output, this usage is explained in the OPERANDS section. Otherwise, if such a utility uses operands to represent files, it is implementation-defined whether the operand '-' stands for standard input (or standard output), or for a file named "-". --------------------------------------------------------- AI-099 Topic: df file operand The proposed change is hard to parse and, if interpreted strictly, would lead to undefined behavior that surely is not intended. Here's the wording in question: [XSI][Option Start] If the file operand names a special file containing a filesystem, df may write the amount of free space in that file system.[Option End]. Otherwise, df shall write the amount of free space in the file system containing the specified file operand. Here's how I interpret this wording. Under XSI, if the file operand names a special file, then df "may" write the amount of free space. It also may do nothing (because the "Otherwise" clause does not apply). Surely it's not intended that df do nothing in this case. The original submitter proposed "shall" instead of "may", and that makes more sense grammatically. If it was the intent to accept the original submitter's request, then you can fix things by changing "may" to "shall" in the above quote. Another possible objection just now occurs to me. Do you want XSI behavior to be an extension to non-XSI behavior? If so, then you'll need wording that is something like this. If the file operand names a file other than a special file containing a file system, df shall write the amount of free space in the file system containing the specified file operand. [XSI][Option Start] Otherwise, df shall write the amount of free space in that file system.[Option End] PS. A nit: "filesystem" should be "file system". ------------------------------------------------------------ AI-100 Topic: tail -c 0, -n 0 The rationale says that "tail -n -f 0" is clearly specified. This must be a typo: "tail -f -n 0" must have been intended. The response says that "tail -n 0" differs from "tail -n +0", but I don't see why this uncontroversial point is relevant, as the original defect report never talked about "tail -n +0". Most importantly, the interpretation response says that the standard is clear, but I disagree: it's not clear. Here's why. tail's DESCRIPTION says "Both line and byte counts start from 1". From this I inferred that "tail -n 0" has undefined behavior because it uses a line count that does not "start from 1". This inference was reinforced by the fact that "head -n 0" clearly has undefined behavior. So I was surprised to see from the draft interpretation that it was intended that "tail -n 0" have clearly-specified behavior. I propose the following change, to make the standard clearer in this area. Before XCU page 898 line 34857, insert: The application shall ensure that _number_ is nonzero if its sign is '+'. If its sign is '-' or absent, a zero _number_ shall cause copying to begin at the end of the file.