Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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
Reporter shware_systems View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Interpretation Required  
Name Mark Ziegast
Organization
User Reference
Section XCU 1.5
Page Number 2317
Line Number 73503-6
Interp Status Approved
Final Accepted Text See Note: 0002175
Summary 0000813: Utility numeric argument syntax requirements ambiguous
Description 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 6.4.4.1 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 6.4.4.1 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 6.4.4.1 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.
Desired Action For TC2, as a paragraph after Line 73506, I believe it should be specific for numeric arguments that the decimal integer format of Section 6.4.4.1 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 6.4.4.1 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.
Tags tc2-2008
Attached Files

- Relationships
related to 0000375Under Reviewajosey 1003.1(2008)/Issue 7 Extend test/[...] conditionals: ==, <, >, -nt, -ot, -ef 

-  Notes
(0002099)
shware_systems (reporter)
2014-01-09 20:07

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.
(0002175)
nick (manager)
2014-03-06 17:07
edited on: 2014-03-06 17:09

Interpretation response
------------------------
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.

Rationale:
-------------
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.

(0002214)
ajosey (manager)
2014-04-01 13:34

Interpretation proposed: 1 April 2014
(0002239)
ajosey (manager)
2014-05-01 10:54

Interpretation approved May 1 2014

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker