Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000559 [1003.1(2008)/Issue 7] Shell and Utilities Objection Omission 2012-04-26 17:17 2020-03-20 09:29
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Eric Blake
Organization Red Hat
User Reference ebb.arithmetic_expansion
Section 2.6.4
Page Number 2310
Line Number 72861
Interp Status Approved
Final Accepted Text Note: 0001238
Summary 0000559: arithmetic expansion should honor 'set -u'
Description The standard is silent on whether 'set -u' affects arithmetic expansion
that parses an unset shell variable name. Besides, if 'x' is unset,
it seems odd for 'echo $((x))' to succeed where 'echo $(($x))' fails,
especially since the standard requires the two constructs to behave
identically when 'x' is set to an integral value.

Since the behavior of arithmetic expansion in the shell was modeled
after ksh behavior, where set -u has an impact, this proposal adds that
requirement. On the other hand, while at least ksh and bash error out,
my testing showed that dash and zsh currently do not flag an error;
forcing the requirement would require these implementations to change,
so the group may instead choose to go with a solution that allows both
behaviors.
Desired Action At line 72681, after:

If the shell variable x contains a value that forms a valid integer
constant, then the arithmetic expansions "$((x))" and "$(($x))" shall
return the same value.

add a sentence:

If set -u is in effect, any unset parameter in the resulting arithmetic
expression shall cause the expansion to fail.
Tags issue8
Attached Files

- Relationships
related to 0000155Closedajosey set -u should require an error when $1 etc. are unset 
related to 0000280Closedajosey description is not clear enought on what happens if the shell immediately exits 

-  Notes
(0001212)
geoffclare (manager)
2012-04-27 08:20

The proposed wording is too vague: it could be interpreted as
applying to assignments of unset variables, e.g.
$((unsetvar = setvar+1))

Also, in TC1 the description of the set -u option includes details
that should apply to this case, such as "it [the shell] shall write
a message to standard error and shall not execute the command
containing the expansion, but for the purposes of setting the '?'
special parameter and the exit status of the shell the command shall
be treated as having been executed and returned an exit status of
between 1 and 125 inclusive." The proposed change bypasses this
by separately specifying that the effect of -u on arithmetic
expansion is to "cause the expansion to fail".

I suggest that instead of making a change in 2.6.4 we should
update the description of set -u so that it begins:

    When the shell tries to expand, in a parameter expansion or
    an arithmetic expansion, an unset parameter other than the '@'
    and '*' special parameters, it shall write ...
(0001238)
geoffclare (manager)
2012-05-10 15:25

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

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

On page 2359 line 74590 section set, after applying change number
XCU/TC1/2008/0047 from TC1, change:

    When the shell tries to expand an unset parameter other than
    the '@' and '*' special parameters, it shall write

to:

    When the shell tries to expand, in a parameter expansion or
    an arithmetic expansion, an unset parameter other than the '@'
    and '*' special parameters, it shall write
(0001288)
ajosey (manager)
2012-06-29 16:15

Interpretation proposed 29 June 2012 for final 45 day review
(0001351)
ajosey (manager)
2012-08-30 09:13

Interpretation approved 30 Aug 2012

- Issue History
Date Modified Username Field Change
2012-04-26 17:17 eblake New Issue
2012-04-26 17:17 eblake Status New => Under Review
2012-04-26 17:17 eblake Assigned To => ajosey
2012-04-26 17:17 eblake Name => Eric Blake
2012-04-26 17:17 eblake Organization => Red Hat
2012-04-26 17:17 eblake User Reference => ebb.arithmetic_expansion
2012-04-26 17:17 eblake Section => 2.6.4
2012-04-26 17:17 eblake Page Number => 2310
2012-04-26 17:17 eblake Line Number => 72861
2012-04-26 17:17 eblake Interp Status => ---
2012-04-26 17:18 eblake Relationship added related to 0000155
2012-04-26 17:19 eblake Description Updated
2012-04-27 08:20 geoffclare Note Added: 0001212
2012-05-10 15:25 geoffclare Note Added: 0001238
2012-05-10 15:26 geoffclare Interp Status --- => Pending
2012-05-10 15:26 geoffclare Final Accepted Text => Note: 0001238
2012-05-10 15:26 geoffclare Status Under Review => Interpretation Required
2012-05-10 15:26 geoffclare Resolution Open => Accepted As Marked
2012-05-10 15:26 geoffclare Tag Attached: issue8
2012-05-11 08:09 geoffclare Relationship added related to 0000280
2012-06-29 16:15 ajosey Interp Status Pending => Proposed
2012-06-29 16:15 ajosey Note Added: 0001288
2012-08-30 09:13 ajosey Interp Status Proposed => Approved
2012-08-30 09:13 ajosey Note Added: 0001351
2020-03-20 09:29 geoffclare Status Interpretation Required => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker