View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000806 | 1003.1(2013)/Issue7+TC1 | System Interfaces | public | 2013-12-01 19:22 | 2019-06-10 08:55 |
Reporter | dalias | Assigned To | |||
Priority | normal | Severity | Editorial | Type | Clarification Requested |
Status | Closed | Resolution | Accepted As Marked | ||
Name | Rich Felker | ||||
Organization | musl libc | ||||
User Reference | |||||
Section | fnmatch | ||||
Page Number | 881 | ||||
Line Number | 29477-29480 | ||||
Interp Status | Approved | ||||
Final Accepted Text | 0000806:0002147 | ||||
Summary | 0000806: fnmatch behavior unclear when pattern ends in backslash | ||||
Description | As fnmatch is specified, "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." My interpretation is that a backslash at the end of pattern is not "a <backslash> character in pattern followed by any other character", and thus this rule does not apply; therefore, such a backslash is to be treated like any other literal. However, I initially thought this was an erroneous pattern, and I could see others conceivably interpreting the terminating null of pattern as a character so that the final backslash would "escape" the null and would either match the terminating null in string (if it's treated as part of string) or fail to be matchable (since a null character cannot appear in a string). | ||||
Desired Action | Please clarify which interpretation is correct, if any, and what requirements are placed on an implementation when pattern ends in a backslash. | ||||
Tags | tc2-2008 |
|
From Line 75038, XCU 2.13.1 "This escaping <backslash> is discarded." . As the terminating NUL is not part of the pattern, and is specifically disallowed as being part of a pattern by 2.13.1, it seems a trailing <backslash> is simply supposed to be discarded and doesn't match anything. Suggest at Page 881, Line 29479, Insert after "string.": "A single <backslash> as the last character of a pattern shall be ignored rather than return an ill-formed escape sequence error." |
|
XCU is not normative for the fnmatch function, only for utilities. While I agree it may make sense to make it consistent, I think that deviates from the current wording of the standard. As for the suggested insertion, the way you've worded it is self-contradictory. Being "ignored" and treated "as an ill-formed escape sequence" are mutually exclusive. The former would imply "a\" matches "a". The latter would imply that a pattern of "a\" is an error which required fnmatch to a return a value distinct from both 0 and FNM_NOMATCH. |
|
This is one of the few cases where it is cross volume normative, rather than repeat ALL the material from the shell language chapter related to patterns. That XCU page cross refs to fnmatch() specifically. I've edited the suggested text. |
|
Test program:#include <fnmatch.h> #include <stdio.h> int main(int argc, char *argv[]) { int err; switch (err = fnmatch(argc > 2 ? argv[2] : "*\\", argc > 1 ? argv[1] : "", FNM_PATHNAME)) { case 0: printf("Match\n"); break; case FNM_NOMATCH: printf("No match\n"); break; default: printf("Error\n"); break; } return 0; } |
|
OS X prints "No match" for the test program in 0000806:0002126 |
|
Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- Existing practice is for a pattern ending in an unescaped <backslash> not to match anything, but it would be useful to allow implementations to diagnose this as user error. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- At page 881 line 29479 after: In particular, "\\" shall match a <backslash> in string. Add: If pattern ends with an unescaped <backslash>, fnmatch() shall return a non-zero value (indicating either no match or an error). Cross-volume change to XCU... At page 2354 line 75017 section 2.13.1 after: The escaping <backslash> shall be discarded. Add: If a pattern ends with an unescaped <backslash>, it is unspecified whether the pattern does not match anything or the pattern is treated as invalid. |
|
Interpretation Proposed 21 Feb 2014 |
|
Interpretation Approved: 25 March 2014 |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-12-01 19:22 | dalias | New Issue | |
2013-12-01 19:22 | dalias | Name | => Rich Felker |
2013-12-01 19:22 | dalias | Organization | => musl libc |
2013-12-01 19:22 | dalias | Section | => fnmatch |
2013-12-01 19:22 | dalias | Page Number | => unknown |
2013-12-01 19:22 | dalias | Line Number | => unknown |
2013-12-17 08:51 | shware_systems | Note Added: 0002077 | |
2013-12-17 08:51 | shware_systems | Note Edited: 0002077 | |
2013-12-17 18:15 | dalias | Note Added: 0002079 | |
2013-12-17 19:27 | shware_systems | Note Added: 0002080 | |
2013-12-17 19:34 | shware_systems | Note Edited: 0002077 | |
2013-12-17 19:56 | Don Cragun | Page Number | unknown => 881 |
2013-12-17 19:56 | Don Cragun | Line Number | unknown => 29477-29480 |
2013-12-17 19:56 | Don Cragun | Interp Status | => --- |
2014-02-06 17:33 | nick | Note Added: 0002126 | |
2014-02-07 10:05 | Don Cragun | Note Added: 0002133 | |
2014-02-20 17:31 | geoffclare | Interp Status | --- => Pending |
2014-02-20 17:31 | geoffclare | Note Added: 0002147 | |
2014-02-20 17:31 | geoffclare | Status | New => Interpretation Required |
2014-02-20 17:31 | geoffclare | Resolution | Open => Accepted As Marked |
2014-02-20 17:32 | geoffclare | Final Accepted Text | => 0000806:0002147 |
2014-02-20 17:32 | geoffclare | Tag Attached: tc2-2008 | |
2014-02-20 17:35 | eblake | Note Edited: 0002147 | |
2014-02-21 15:38 | ajosey | Interp Status | Pending => Proposed |
2014-02-21 15:38 | ajosey | Note Added: 0002151 | |
2014-03-25 13:42 | ajosey | Interp Status | Proposed => Approved |
2014-03-25 13:42 | ajosey | Note Added: 0002200 | |
2019-06-10 08:55 | agadmin | Status | Interpretation Required => Closed |