A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1546 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1546 Category: Base Definitions and Headers Type: Enhancement Request Severity: Editorial Priority: normal Status: Resolved Name: Christoph Anton Mitterer Organization: User Reference: Section: 9.3 Basic Regular Expressions Page Number: N/A Line Number: N/A Interp Status: --- Final Accepted Text: https://austingroupbugs.net/view.php?id=1546#c5755 Resolution: Accepted As Marked Fixed in Version: ====================================================================== Date Submitted: 2022-01-08 03:48 UTC Last Modified: 2022-03-25 22:57 UTC ====================================================================== Summary: BREs: reserve \? \+ and \| ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- has duplicate 0000773 Summary: Add \+, \?, and \| to Basic Re... ======================================================================
---------------------------------------------------------------------- (0005766) calestyo (reporter) - 2022-03-25 22:57 https://austingroupbugs.net/view.php?id=1546#c5766 ---------------------------------------------------------------------- May I also add the following: a) Not sure whether https://austingroupbugs.net/view.php?id=773 is really to be considered a duplicate of this. This issue was merely about preventing "\?", "\+", and "\|" to get any completely other meaning than that from ERE. While #773 rather asked for defining them to ONLY have the special meaning (not either special or literal - as the above draft resolves it). b) While the draft in 5755 prevents (a) from happening (e.g. \+ couldn't suddenly mean something completely different) I'm still a bit sceptical on whether that's the best way to go. It merely records the current situation of implementations - but with that also statically codifies the two different interpretations (literal ? + \ vs. special). So we'd get non-portable behaviour even deeper into the standard than it was before, where from the standard's PoV any use of "\?", "\+", and "\|" was simply undefined. I realise that it would be problematic to follow the spirit of #773 and define "\?", "\+", and "\|" to have ONLY the special meaning, when there are implementations (you've mentioned Solaris, HP-UX, AIX) who behave already different. OTOH, if an implementation assigns it's own semantics to undefined parts of a standard, it must always assume that sooner or later it could get compatibility issues. The question arises: Do Solaris/HP-UX/AIX really give "\?", "\+", and "\|" the literal meaning on purpose (or is it perhaps just an undocumented side-effect of the implementation),... is it even used there,... would they be willing to adapt? Depending on the answers, it could make sense to follow a different path. And even if that doesn't seem feasible right now, one could perhaps add something to "future directions", indicating that a future standard might require "\?", "\+", and "\|" to have ONLY the special meaning. This would encourage any new implementations to follow that. And as long as any implementations exist (possibly even forever),... the "future direction" would never need to become true, so no one should be sad. Issue History Date Modified Username Field Change ====================================================================== 2022-01-08 03:48 calestyo New Issue 2022-01-08 03:48 calestyo Name => Christoph Anton Mitterer 2022-01-08 03:48 calestyo Section => 9.3 Basic Regular Expressions 2022-01-08 03:48 calestyo Page Number => N/A 2022-01-08 03:48 calestyo Line Number => N/A 2022-01-28 11:21 mirabilos Note Added: 0005636 2022-01-28 23:10 calestyo Note Added: 0005639 2022-03-03 06:56 Don Cragun Note Added: 0005731 2022-03-03 07:03 Don Cragun Note Edited: 0005731 2022-03-10 17:09 geoffclare Note Added: 0005738 2022-03-10 17:09 geoffclare Interp Status => --- 2022-03-10 17:09 geoffclare Final Accepted Text => https://austingroupbugs.net/view.php?id=1546#c5738 2022-03-10 17:09 geoffclare Status New => Resolved 2022-03-10 17:09 geoffclare Resolution Open => Accepted As Marked 2022-03-10 17:10 geoffclare Tag Attached: issue8 2022-03-10 17:44 calestyo Note Added: 0005740 2022-03-12 21:01 Don Cragun Relationship added related to 0000773 2022-03-12 21:12 calestyo Note Added: 0005744 2022-03-12 21:13 calestyo Note Edited: 0005744 2022-03-14 10:08 geoffclare Note Added: 0005748 2022-03-14 10:08 geoffclare Status Resolved => Under Review 2022-03-14 10:08 geoffclare Resolution Accepted As Marked => Reopened 2022-03-14 13:50 calestyo Note Added: 0005749 2022-03-14 14:31 geoffclare Note Added: 0005750 2022-03-18 09:32 geoffclare Note Added: 0005755 2022-03-24 15:29 geoffclare Final Accepted Text https://austingroupbugs.net/view.php?id=1546#c5738 => https://austingroupbugs.net/view.php?id=1546#c5755 2022-03-24 15:29 geoffclare Status Under Review => Resolved 2022-03-24 15:29 geoffclare Resolution Reopened => Accepted As Marked 2022-03-24 15:34 geoffclare Relationship replaced has duplicate 0000773 2022-03-25 22:41 calestyo Note Added: 0005765 2022-03-25 22:57 calestyo Note Added: 0005766 ======================================================================
