|Anonymous | Login||2018-08-18 12:29 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000813||[1003.1(2013)/Issue7+TC1] Shell and Utilities||Objection||Omission||2014-01-08 08:15||2014-05-01 10:54|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||See Note: 0002175|
|Summary||0000813: Utility numeric argument syntax requirements ambiguous|
The text currently has:
The following utilities support files of any size up to the maximum that can be created by the
implementation. This support includes correct writing of file size-related values (such as file
sizes and offsets, line numbers, and block counts) and correct interpretation of command line
arguments that contain such values.
This requirement of 'correct interpretation' of numeric strings as arguments representing values greater than LONG_MAX supercedes XBD 12.1, #6 which limits values to LONG_MAX or less as required. What is missing is an explicit statement of which numeric syntax and absolute range those listed utilities are now expected to process.
The only text referencing an expectation on syntax that includes an extended range is the blanket "Unless otherwise noted, the arithmetic and semantic concepts (precision, type conversion, control flow, and so on) shall be equivalent to those defined in the ISO C standard, as described in the following sections." of XCU 1.1.2. Section 7.20.1 of C groups strtoll() and strtoull() under Numeric conversion functions, so they can nominally be considered a form of type conversion. It may be argued this wasn't the intent, that only conversions between different sizes of integer and floating values was implied and how these interact with operators and control statements, but I don't think a conformance distinction can be drawn as worded.
The ambiguity comes in because the C standard defines two syntaxes for conversion from textual data to integer binary representation, that of Section 184.108.40.206 which is context independent for base 8, 10, or 16, and one for a context dependent range of bases, of which the scanf() and printf() interfaces only support those common 3. While the language does permit either form to be used in some fashion, the explicit requirement on the sh utility, per XCU 2.6.4 Arithmetic Expansion, of supporting Section 220.127.116.11 implies that the other utilities of XCU 1.5 are to support this format also so text values acceptable to expansions may be passed as utility arguments or positional parameters to command expansions as well.
Additionally, that there is no explicit mention in XBD 12.1 that numeric values are permitted to have superfluous leading zero values implies only the decimal integer format of Section 18.104.22.168 is required, limited in range of -LONG_MAX to +LONG_MAX, as that is the minimum that meets how numbers may be represented mathematically. Support of leading zeros in a numeric argument is a possibly non-portable optional behavior, in other words, since they're optional in mathematics.
For TC2, as a paragraph after Line 73506, I believe it should be specific for numeric arguments that the decimal integer format of Section 22.214.171.124 with a range of -LLONG_MAX to +LLONG_MAX shall be supported, and those utilities may support the octal and hexadecimal formats as well, with an explicit reservation that a future version of the standard may require all utilities to process those alternate formats and possibly more. The caveat that any utility may return ERANGE as appropriate to an implementations' specific limits would still hold.
Exact wording I expect to be hashed out, but this is what I see as the interpretation the current language supports most. This is consistent with current practice, and XBD 12.1 permitting extended ranges, but removes the ambiguity of which syntax form is expected. For clarity, the first bullet of XBD 12.1 #6 can be changed to "...integer consistent with the syntax of Section 126.96.36.199 of the C standard.", with maybe a footnote that "Some current utility implementations may also permit leading zeros but portable applications shall not rely on this behavior."
Adding the reservation now provides notice that Issue 8 will require it, albeit some with signed long and some with signed long long as nominal range, for consistency between usage in the shell and shell variables that may be expanded as arguments to those utilities. It also leaves room that some compatible extensions to the syntax, as discussed on the mailing list as possibly desirable, may be incorporated as CX extensions if the then current version of the C standard doesn't provide similar functionality.
|As this issue came up as part of the mailing list discussion for Item 375, I believe a Relationships: link to that may be in order, as that possibly depends upon this.|
edited on: 2014-03-06 17:09
The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.
The normative requirement in XCU 1.5 does not match the syntax utility guidelines which suggest very large values may be supported but are not required to be.
Notes to the Editor (not part of this interpretation):
On page 214, after line 7104, add a new bullet
* When the utility description states that the number is a file size-related value (such as a file size or offset, line number, or block count), numerals in the range 0 to the maximum file size supported by the implementation are syntactically recognized as numeric values (see XCU 1.5 Considerations for Utilities in Support of Files of Arbitrary Size). Where negative values are permitted, any value in the range -(maximum file size) to the maximum file size is accepted.
|Interpretation proposed: 1 April 2014|
|Interpretation approved May 1 2014|
|2014-01-08 08:15||shware_systems||New Issue|
|2014-01-08 08:15||shware_systems||Name||=> Mark Ziegast|
|2014-01-08 08:15||shware_systems||Section||=> XCU 1.5|
|2014-01-08 08:15||shware_systems||Page Number||=> 2317|
|2014-01-08 08:15||shware_systems||Line Number||=> 73503-6|
|2014-01-09 20:07||shware_systems||Note Added: 0002099|
|2014-03-06 17:07||nick||Note Added: 0002175|
|2014-03-06 17:07||nick||Interp Status||=> Pending|
|2014-03-06 17:07||nick||Final Accepted Text||=> See Note: 0002175|
|2014-03-06 17:07||nick||Status||New => Interpretation Required|
|2014-03-06 17:07||nick||Resolution||Open => Accepted As Marked|
|2014-03-06 17:07||nick||Tag Attached: tc2-2008|
|2014-03-06 17:08||eblake||Relationship added||related to 0000375|
|2014-03-06 17:09||nick||Note Edited: 0002175|
|2014-03-06 17:09||nick||Note Edited: 0002175|
|2014-04-01 13:34||ajosey||Interp Status||Pending => Proposed|
|2014-04-01 13:34||ajosey||Note Added: 0002214|
|2014-05-01 10:54||ajosey||Interp Status||Proposed => Approved|
|2014-05-01 10:54||ajosey||Note Added: 0002239|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|