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
0001130 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Objection Error 2017-03-21 17:07 2019-10-31 11:39
Reporter Antonio Diaz View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Antonio Diaz
Organization GNU
User Reference
Section ed
Page Number 2682
Line Number 87448-87449
Interp Status ---
Final Accepted Text See Note: 0004105
Summary 0001130: Address 0 does not make sense for the c command
Description The synopsis of the c command states that "Address 0 shall be valid for this command; it shall be interpreted as if address 1 were specified".

The RATIONALE of the ed utility states that "For consistency with the a and r commands and better user functionality, the i and c commands must also accept an address of 0, in which case 0i is treated as 1i and likewise for the c command".

But accepting 0 as a valid address for the c command does not make sense because the c command executes a d command, which does not admit an address of 0. With respect to addresses, the c command should be treated as the d command, not as the a, i or r commands, because a, i and r do not delete anything.
See discussion at http://lists.gnu.org/archive/html/bug-ed/2016-04/msg00009.html [^]
Desired Action Remove from the synopsis of the c command and from the RATIONALE the requirement that the c command must accept address 0.
Tags tc3-2008
Attached Files

- Relationships
related to 0001131Applied The synopsis of the i command is wrong and inconsistent with the synopsis of the a command 

-  Notes
(0004098)
geoffclare (manager)
2018-08-31 14:16

I did some digging into the history...

This requirement was not in the original POSIX.2-1992. It came into the standard via the .2b amendment. Unfortunately .2b does not give a clear explanation for the change. It specifies this change followed by a change to the Global command, and then says "The preceding two changes are the result of interpretation request PASC 1003.2-92 #119 submitted for IEEE Std 1003.2-1992." Interpretation #119 can be found in this online zip file:

http://standards.ieee.org/findstds/interps/1003.2-1992_interp.zip [^]

but it is entirely about the Global command; there is no mention of the Change command. Presumably the update to the Change command arose when discussion of interpretation #119 digressed, but it is a shame that the .2b developers did not capture the reason for the change as rationale in .2b.

I wonder whether they were considering ranges - it makes sense for 0,2c to work the same as 1,2c - however I agree with Antonio that specifying 0c to be the same as 1c makes no sense. The only behaviour for 0c that makes sense to me would be for it to work like 0a, by analogy with s/^/string/ which inserts the string at the beginning of a line.

Since most ed implementations changed to support address 0 in order to conform to .2b, I suggest that rather than removing the requirement, we should make support for address 0 optional and say that if it is supported, the behaviour is unspecified.
(0004105)
nick (manager)
2018-09-06 16:36

Suggested change: On page 2682, line 87448, delete "Address 0 shall be valid for this command; it shall be interpreted as if address 1 were specified."
On page 2691, lines 87803-87805, change

For consistency with the a and r commands and better user functionality, the i and c commands must also accept an address of 0, in which case 0i is treated as 1i and likewise for the c command.

to

For consistency with the a and r commands and better user functionality, the i command also accepts an address of 0. However, it is unspecified if <tt>0i</tt> is treated as <tt>1i</tt> (which will fail if the buffer is empty), or means insert at the beginning of the buffer (which will succeed even if the buffer is empty). Earlier versions of this standard required address 0 for the c command to be treated as 1 also, but this requirement has been removed, though implementations are permitted to do this as an extension.
(0004107)
nick (manager)
2018-09-06 16:43
edited on: 2018-09-06 16:43

Note that the resolution in Note: 0004105 includes rationale for the change in 0001131


- Issue History
Date Modified Username Field Change
2017-03-21 17:07 Antonio Diaz New Issue
2017-03-21 17:07 Antonio Diaz Name => Antonio Diaz
2017-03-21 17:07 Antonio Diaz Organization => GNU
2017-03-21 17:07 Antonio Diaz Section => ed
2017-03-21 17:07 Antonio Diaz Page Number => 0
2017-03-21 17:07 Antonio Diaz Line Number => 0
2017-03-21 17:10 Antonio Diaz Issue Monitored: Antonio Diaz
2017-03-21 18:26 salty-horse Issue Monitored: salty-horse
2018-08-30 16:24 nick Page Number 0 => 2682
2018-08-30 16:24 nick Line Number 0 => 87448-87449
2018-08-30 16:24 nick Interp Status => ---
2018-08-31 14:16 geoffclare Note Added: 0004098
2018-09-06 16:33 geoffclare Relationship added related to 0001131
2018-09-06 16:36 nick Note Added: 0004105
2018-09-06 16:37 nick Final Accepted Text => See Bugnote:0004105
2018-09-06 16:37 nick Status New => Resolution Proposed
2018-09-06 16:37 nick Resolution Open => Accepted As Marked
2018-09-06 16:37 nick Tag Attached: tc3-2008
2018-09-06 16:38 nick Status Resolution Proposed => Resolved
2018-09-06 16:43 nick Note Added: 0004107
2018-09-06 16:43 nick Note Edited: 0004107
2018-09-07 08:17 geoffclare Final Accepted Text See Bugnote:0004105 => See Note: 0004105
2019-10-31 11:39 geoffclare Status Resolved => Applied


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