View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001582 | 1003.1(2016/18)/Issue7+TC2 | Shell and Utilities | public | 2022-04-30 10:23 | 2024-06-11 09:07 |
| Reporter | nmeum | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Sören Tempel | ||||
| Organization | |||||
| User Reference | |||||
| Section | ed | ||||
| Page Number | 2691 | ||||
| Line Number | 87831 | ||||
| Interp Status | Approved | ||||
| Final Accepted Text | 0001582: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 | ||||
|
|
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,$,$". |
|
|
Interpretation Proposed: 6 May 2022 |
|
|
Approved: 7 June 2022 |
| 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 | => 0001582: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 |
