Austin Group Defect Tracker

Aardvark Mark IV

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 2024-06-11 09:08
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Geoff Clare
Organization The Open Group
User Reference
Section fnmatch()
Page Number 890
Line Number 30061
Interp Status Approved
Final Accepted Text See Note: 0004561
Summary 0001287: fnmatch() handling of backslash in bracket expressions
Description 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.
Desired Action 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.

Change:
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].
Tags tc3-2008
Attached Files

- Relationships

-  Notes
(0004558)
shware_systems (reporter)
2019-09-17 16:07

 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].

Followed by:
A <backslash> followed by a <NUL> shall be treated as if the <backslash> was not provided and terminates the pattern.

or:
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.
(0004559)
geoffclare (manager)
2019-09-19 12:18

 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.
(0004561)
nick (manager)
2019-09-23 15:33

 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:
-------------

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).


to:
    
If pattern ends with an unescaped <backslash>, the behavior is unspecified.
(0004596)
agadmin (administrator)
2019-10-07 15:15

 Interpretation proposed: 7 October 2019
(0004642)
agadmin (administrator)
2019-11-11 12:19

 Interpretation Approved: 11 Nov 2019

- Issue History
Date Modified Username Field Change
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
2024-06-11 09:08 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker