View Issue Details

IDProjectCategoryView StatusLast Update
00008131003.1(2013)/Issue7+TC1Shell and Utilitiespublic2019-06-10 08:55
Reportershware_systems Assigned To 
PrioritynormalSeverityObjectionTypeOmission
Status ClosedResolutionAccepted As Marked 
NameMark Ziegast
Organization
User Reference
SectionXCU 1.5
Page Number2317
Line Number73503-6
Interp StatusApproved
Final Accepted TextSee 0000813:0002175
Summary0000813: Utility numeric argument syntax requirements ambiguous
DescriptionThe 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 ActionFor 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.
Tagstc2-2008

Relationships

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

Activities

shware_systems

2014-01-09 20:07

reporter   bugnote:0002099

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.

nick

2014-03-06 17:07

manager   bugnote:0002175

Last edited: 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.

ajosey

2014-04-01 13:34

manager   bugnote:0002214

Interpretation proposed: 1 April 2014

ajosey

2014-05-01 10:54

manager   bugnote:0002239

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 0000813: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
2019-06-10 08:55 agadmin Status Interpretation Required => Closed