View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001914 | 1003.1(2024)/Issue8 | Shell and Utilities | public | 2025-03-15 16:20 | 2025-03-20 22:53 |
| Reporter | rillig | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Resolved | Resolution | Accepted As Marked | ||
| Name | Roland Illig | ||||
| Organization | |||||
| User Reference | |||||
| Section | Issue 8, Volume 3, expr | ||||
| Page Number | 2916 | ||||
| Line Number | 97319, 97321 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001914:0007127 | ||||
| Summary | 0001914: expr: short-circuit evaluation | ||||
| Description | Line 97319 says: > expr1 & expr2: Returns the evaluation of expr1 if neither expression evaluates to null or zero; otherwise, returns zero. Line 97321 says: > expr1 | expr2: Returns the evaluation of expr1 if it is neither null nor zero; otherwise, returns the evaluation of expr2 if it is not null; otherwise, zero. These sentences differ in structure even though they describe closely related operators. In particular, line 97321 sounds as if in 'expr1 | expr2', the expr2 part should only be evaluated if necessary, while line 97319 sounds like both expr1 and expr2 should always be evaluated, even if expr1 is already false. | ||||
| Desired Action | Align the wording of the two operators to be structurally the same, except for the trailing "otherwise zero", as that is unique to "|". | ||||
| Tags | tc1-2024 | ||||
|
|
It is not the "otherwise zero" that is unique to "|", it is the "returns the evaluation of expr2" part. The "&" operation never returns expr2. Whether or not these operations short-circuit is internal implementation detail. Since expr does not have any operations with side effects (like ++), the application can't tell the difference. As for the desired action, "Align the wording of the two operators to be structurally the same", I can't see any way to do that which would result in text I'd be happy with. For the description of "&" to have three parts like "|", there would necessarily be duplication in two of the parts, which would be confusing. E.g.: Returns zero if expr1 is either null or zero; otherwise, returns zero if expr2 is either null or zero; otherwise, returns the evaluation of expr1.which cries out for the first two parts to be combined. |
|
|
expr 123 \| 1 / 0 The implementations from GNU coreutils, NetBSD and FreeBSD check for a division by zero. On these implementations there's the difference between returning "123" or reporting "expr: division by zero", depending on whether the operators perform short-circuit evaluation. The wording seems to intentionally omit whether short-circuit evaluation is forbidden, allowed or required, so the wording is fine with me. I just wasn't sure whether the wording was intentional, so I had hoped for a wording that would expression the intention more clearly. |
|
|
Ah yes, I hadn't thought of an error message as a possible "side effect". If implementations differ on whether they evaluate expr2, I suggest we make it explicitly unspecified. Suggested changes... On page 2916 line 97320 section expr, add a sentence in "Description" column for "&": If expr1 is null or zero, it is unspecified whether expr2 is evaluated. On page 2916 line 97323 section expr, add a sentence in "Description" column for "|": If expr1 is neither null nor zero, it is unspecified whether expr2 is evaluated. After page 2919 line 97410 section expr (RATIONALE), add a paragraph: Implementations differ as to whether the '&' and '|' operators ``short-circuit'' (that is, whether they evaluate expr2 if the return value can be deduced from evaluating just expr1). Consequently, the observed behavior may differ when evaluating expr2 would cause an error (or a signal), such as dividing by zero. |
|
|
Are there implementations that do NOT short-circuit? Obviously, speed isn't a critical need here, but short-circuiting is pretty common behavior for "and" and "or" when you look across the landscape. I know Ada has both operations ("and then" short-circuits while "and" doesn't), but if the specification can specifically require short-circuits, that would eliminate some unnecessary variation. |
|
|
> Are there implementations that do NOT short-circuit? Solaris and macOS don't short-circuit. |
|
|
Thank you Geoff, your wording fits perfectly what I wanted to know. I asked in the first place because I switched the NetBSD implementation from always-evaluate to short-circuit but then noticed that the wording in the standard wasn't explicit enough to force this change. GNU coreutils: short-circuit NetBSD < 11: always-evaluate NetBSD >= 11: short-circuit FreeBSD: always-evaluate OpenBSD: always-evaluate |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-03-15 16:20 | rillig | New Issue | |
| 2025-03-18 10:05 | geoffclare | Note Added: 0007121 | |
| 2025-03-18 18:45 | rillig | Note Added: 0007126 | |
| 2025-03-20 09:42 | geoffclare | Note Added: 0007127 | |
| 2025-03-20 14:20 | dwheeler | Note Added: 0007128 | |
| 2025-03-20 15:16 | geoffclare | Note Added: 0007129 | |
| 2025-03-20 15:18 | geoffclare | Status | New => Resolved |
| 2025-03-20 15:18 | geoffclare | Resolution | Open => Accepted As Marked |
| 2025-03-20 15:18 | geoffclare | Interp Status | => --- |
| 2025-03-20 15:18 | geoffclare | Final Accepted Text | => 0001914:0007127 |
| 2025-03-20 15:18 | geoffclare | Tag Attached: tc1-2024 | |
| 2025-03-20 22:53 | rillig | Note Added: 0007131 |
