Anonymous | Login | 2024-09-12 21:58 UTC |
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 | ||
0001575 | [Issue 8 drafts] Base Definitions and Headers | Editorial | Enhancement Request | 2022-04-05 01:15 | 2022-04-08 08:51 | ||
Reporter | calestyo | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Withdrawn | ||||
Status | Closed | Product Version | Draft 2.1 | ||||
Name | Christoph Anton Mitterer | ||||||
Organization | |||||||
User Reference | |||||||
Section | 9.3.5 RE Bracket Expression | ||||||
Page Number | 169 | ||||||
Line Number | 5872 | ||||||
Final Accepted Text | |||||||
Summary | 0001575: imrpove indication that [^] as a bracket expression is not valid | ||||||
Description |
Hey. When working on issue #1551 I stumbled over the question that it's a bit vague, whether regular expressions allow a bracket expression that consists of a single <circumflex>, i.e. '[^]'... which should supposedly match the literal <circumflex>. I'd say line 5872: "A matching list expression specifies a list that shall match any single character that is matched by one of the expressions represented in the list. The first character in the list cannot be the <circumflex>." kinda implies that it's *not* possible, because that item "2." describes the matching list, and it says "The first character in the list cannot be the <circumflex>.". |
||||||
Desired Action |
Replace page 169, line 5873: "The first character in the list cannot be the <circumflex>." with: "The first or only character in the list cannot be the <circumflex>." I wonder whether this is enough. cause it would only be in the section that describes "matching lists". What if one e.g. considers '[^]' a non-matching list? That I think however is already ruled out earlier, by page 168, line 5833, which says: "A bracket expression is either a matching list expression or a non-matching list expression. It consists of one or more expressions: ordinary characters, collating elements, collating symbols, equivalence classes, character classes, or range expressions." Thus a non-matching list would need to consist of "one or more <something>", whereas '[^]' (as a thought non-matching list) would miss that <something>. |
||||||
Tags | No tags attached. | ||||||
Attached Files | |||||||
|
Notes | |
(0005782) geoffclare (manager) 2022-04-05 14:32 |
[^] is not a valid bracket expression because it is missing the terminating ']'. [^]] is a valid bracket expression that matches any character except ']'. See XBD 9.3.5 item 1: The <right-square-bracket> (']') shall lose its special meaning and represent itself in a bracket expression if it occurs first in the list (after an initial <circumflex> ('ˆ'), if any). |
(0005787) calestyo (reporter) 2022-04-07 22:55 |
Hmm. I actually had things like []] in mind when asking for the above, cause a non-expert reader could (when not reading everything or understanding its subtle implications) come to the idea that [^] might be a valid special case of a bracket expression, just like []] is. Of course it is not (which I was trying to point even more with my proposed change). But you're right, since [^] is not only not equivalent to '\^' but not even a valid bracket expression at all,... my above proposal wouldn't make sense. We could add a hint like "([^] alone isn't a valid bracket expression)" to the paragraph at line 5872. But I'd agree that this is not necessary. Unless you feel different, please close this issue and sorry for the noise. btw and unrelated: - In 9.3.2 BRE Ordinary Characters, "When not inside a bracket expression, the interpretation of an ordinary character preceded by an unescaped <backslash> is undefined, except for:" doesn't list '^' and '$' which, as per 9.3.8 BRE Expression Anchoring may follow a '\'. (And perhaps the same for EREs.) - 9.3.8 BRE Expression Anchoring, point 1 mentions that a portable BRE, shall escape a subexpressions leading ^ if that shall be literal. But point 2 doesn't mention the same for a trailing '$', though that seems also implementation dependant. Do you think anything should be done about that? |
(0005789) geoffclare (manager) 2022-04-08 08:51 |
Closing as withdrawn, as per the submitter's request in Note: 0005787 |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |