Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001582 [1003.1(2016/18)/Issue7+TC2] Shell and Utilities Editorial Clarification Requested 2022-04-30 10:23 2024-06-11 09:07
Reporter nmeum View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Sören Tempel
Organization
User Reference
Section ed
Page Number 2691
Line Number 87831
Interp Status Approved
Final Accepted Text Note: 0005829
Summary 0001582: Algorithm for computing addresses for "address chains" is not clearly specified
Description The table in the rationale section of the ed specification specifies (among others) the following address handling rules:

Address Addr1 Addr2
,, $ $
;; $ $

As far as I can tell, the handling of such address chains is only discussed in the text of the rationale section. In this regard, the sentence starting at line number 87812 mentions the following:

    Any number of addresses can be provided to commands taking addresses; for example, "1,2,3,4,5p" prints lines 4 and 5, because two is the greatest valid number of addresses accepted by the print command.

In accordance with the address omission rules from line number 87377 and 87380 I would therefore have expected the aforementioned address chains to be evaluated as follows:

,, -> (1,$)(1,$) -> 1,$
;; -> (1,.)(1,.) -> 1,.

I surveyed different implementations of ed(1) regarding the handling of the ",," address chain. Each implementation was testing using `printf "a\nfoo\nbar\nbaz\n.\n,,p\nQ\n" | ed`.

Implementation Addr1 Addr2
OpenBSD 7.0 1 $
FreeBSD 13.0 1 $
NetBSD 9.2 $ $
GNU ed 1.8 $ $
MacOS Catalina $ $

My takeaway from this is, that the algorithm for computing addresses for "address chains" is not clearly specified in POSIX and should be clarified in the text to ensure portability across different implementations. I also encountered a bug report for the GNU implementation <https://lists.gnu.org/archive/html/bug-ed/2018-03/msg00003.html> [^] which acknowledges that the current behavior is insufficiently specified.

On a side note: The ed specification does not clearly spell out the meaning of the status column in the address table. Furthermore, the evaluation order for address chains is also not clearly specified. However, since line number 87825 mandates that 7,5, should evaluate to 5,5 it seems that address chains are right-associative, i.e. 7,(5,). In my opinion, this should also be clarified in the text, preferably in a different section.
Desired Action Add an additional paragraph which clearly spells out the algorithm for evaluating address chains.
Tags tc3-2008
Attached Files

- Relationships

-  Notes
(0005829)
geoffclare (manager)
2022-05-05 16:29

 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:
-------------
In order to evaluate the address list ",," two rules need to be applied, and it is unclear how they interact.

Line 87365 states:
If more than the required number of addresses are provided to a command that requires zero addresses, it shall be an error. Otherwise, if more than the required number of addresses are provided to a command, the addresses specified first shall be evaluated and then discarded until the maximum number of valid addresses remain, for the specified command.


If the "omitted addresses" rule is applied first, then "the addresses specified first" are those that result from that rule, leading to ",," being evaluated as "1,$ 1,$", which is invalid syntax for an address list (unless the implementation accepts this as an extension). If it is applied during the address counting performed for the above rule, then the first ',' becomes "1,$" and then the second ',' is evaluated after this, leading to the above rule being applied to "1,$,$". It is clear from the rationale in the standard, that it is intended for the latter to be used, but the normative text does not say so.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
After line 87382 add a new paragraph:
If an address is omitted between two separators, the rule shall be applied to the first separator and the resulting second address shall be used as the first address for the second separator. For example, with the address list ",," the first ',' becomes "1,$" and the '$' is treated as the first address for the second ',', resulting in "1,$,$".
(0005830)
agadmin (administrator)
2022-05-06 13:21

 Interpretation Proposed: 6 May 2022
(0005846)
agadmin (administrator)
2022-06-07 09:27

 Approved: 7 June 2022

- Issue History
Date Modified Username Field Change
2022-04-30 10:23 nmeum New Issue
2022-04-30 10:23 nmeum Name => Sören Tempel
2022-04-30 10:23 nmeum Section => ed
2022-04-30 10:23 nmeum Page Number => 2691
2022-04-30 10:23 nmeum Line Number => 87831
2022-05-05 16:29 geoffclare Note Added: 0005829
2022-05-05 16:29 geoffclare Interp Status => Pending
2022-05-05 16:29 geoffclare Final Accepted Text => Note: 0005829
2022-05-05 16:29 geoffclare Status New => Interpretation Required
2022-05-05 16:29 geoffclare Resolution Open => Accepted As Marked
2022-05-05 16:30 geoffclare Tag Attached: tc3-2008
2022-05-06 13:21 agadmin Interp Status Pending => Proposed
2022-05-06 13:21 agadmin Note Added: 0005830
2022-06-07 09:27 agadmin Interp Status Proposed => Approved
2022-06-07 09:27 agadmin Note Added: 0005846
2022-06-17 08:39 geoffclare Status Interpretation Required => Applied
2024-06-11 09:07 agadmin Status Applied => Closed

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