|Anonymous | Login||2023-03-31 01:05 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|
|0001287||[1003.1(2016/18)/Issue7+TC2] System Interfaces||Objection||Clarification Requested||2019-09-17 10:30||2019-12-05 11:22|
|Priority||normal||Resolution||Accepted As Marked|
|Organization||The Open Group|
|Final Accepted Text||See Note: 0004561|
|Summary||0001287: fnmatch() handling of backslash in bracket expressions|
The description of fnmatch() says:
If FNM_NOESCAPE is not set in flags, a <backslash> character in pattern followed by any other character shall match that second character in string.Since this describes the handling of backslash independently of the description of backslash as a pattern matching special character in 2.13.1, it is not clear whether the requirement (via the reference to XBD 9.3.5 in 2.13.1) that backslash loses its special meaning within a bracket expression applies here.
However, fnmatch() was invented by the original POSIX.2 developers as a way for C programs to perform the same pattern matching that utilities perform (as described in 2.13) and therefore it is almost certain that the intention was for this paragraph to mean that when FNM_NOESCAPE is not set, fnmatch() handles backslash as described in 2.13.1 and when FNM_NOESCAPE is set, backslash is instead treated as a literal character.
I tested a few implementations: Solaris and HP-UX behave as per 2.13.1, glibc and macOS do not.
Since both behaviours are seen on certified systems, we should issue a "standard is unclear" interpretation to allow either behaviour for Issue 7 conformance, but tighten the requirements for Issue 8 to ensure consistency with find -name/-path and the pax pattern operand.
If FNM_NOESCAPE is not set in flags, a <backslash> character in pattern followed by any other character shall match that second character in string. In particular, "\\" shall match a <backslash> in string.to:
If FNM_NOESCAPE is not set in flags, a <backslash> character can be used as an escape character as described in [xref to 2.13.1].
There should be an exception for <NUL>, imo, as in:
If FNM_NOESCAPE is not set in flags:
A <backslash> character can be used to escape a following character, except for <NUL>, as described in [xref to 2.13.1].
A <backslash> followed by a <NUL> shall be treated as if the <backslash> was not provided and terminates the pattern.
A <backslash> followed by a <NUL> shall be considered an invalid pattern, and the interface shall return with EINVAL stored in errno.
Because the shell has the alternates of double-quoting and <newline> as pattern delimiters, shell tokens not used as utility arguments may include <NUL>, which 2.13.1 has to make allowance for. C strings do not; the use of <NUL> in them as string terminator has priority, that I see. I feel it is clearer to emphasize the distinction here, rather than try to put too much into the resolution of 1284.
Re: Note: 0004558 the case of an unescaped backslash preceding the NUL terminator of the string is covered by the statement at line 30063:
If pattern ends with an unescaped <backslash>, fnmatch() shall return a non-zero value (indicating either no match or an error).
However, since we are planning to change the similar statement in XCU 2.13.1 to say simply that the behaviour is unspecified, we should consider making an equivalent change here.
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.
The intention has always been that fnmatch() (with zero flags argument) should implement pattern matching as described in XCU 2.13.1 and 2.13.2. However, the separate description of backslash handling for fnmatch() makes this unclear as regards the requirements for backslash inside bracket expressions.
Notes to the Editor (not part of this interpretation):
Make the changes in the Desired Action and also change (P890 L30063):
If pattern ends with an unescaped <backslash>, fnmatch( ) shall return a non-zero value (indicating either no match or an error).
If pattern ends with an unescaped <backslash>, the behavior is unspecified.
|Interpretation proposed: 7 October 2019|
|Interpretation Approved: 11 Nov 2019|
|2019-09-17 10:30||geoffclare||New Issue|
|2019-09-17 10:30||geoffclare||Name||=> Geoff Clare|
|2019-09-17 10:30||geoffclare||Organization||=> The Open Group|
|2019-09-17 10:30||geoffclare||Section||=> fnmatch()|
|2019-09-17 10:30||geoffclare||Page Number||=> 890|
|2019-09-17 10:30||geoffclare||Line Number||=> 30061|
|2019-09-17 10:30||geoffclare||Interp Status||=> ---|
|2019-09-17 16:07||shware_systems||Note Added: 0004558|
|2019-09-19 12:18||geoffclare||Note Added: 0004559|
|2019-09-23 15:33||nick||Note Added: 0004561|
|2019-09-23 15:34||nick||Interp Status||--- => Pending|
|2019-09-23 15:34||nick||Final Accepted Text||=> See Note: 0004561|
|2019-09-23 15:34||nick||Status||New => Interpretation Required|
|2019-09-23 15:34||nick||Resolution||Open => Accepted As Marked|
|2019-09-23 15:45||nick||Tag Attached: tc3-2008|
|2019-10-07 15:15||agadmin||Interp Status||Pending => Proposed|
|2019-10-07 15:15||agadmin||Note Added: 0004596|
|2019-11-11 12:19||agadmin||Interp Status||Proposed => Approved|
|2019-11-11 12:19||agadmin||Note Added: 0004642|
|2019-12-05 11:22||geoffclare||Status||Interpretation Required => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|