[moving from embargoed to open discussion] On 5/19/2011 9:53 AM, Joe Orton wrote: > On Wed, May 18, 2011 at 04:11:19PM -0500, William Rowe wrote: >> On 5/18/2011 3:55 PM, Joe Orton wrote: >>> >>> I am comparing 1.3.9 with the tip of the 1.4.x branch. >> >> If you want to fuzz between system fnmatch (linux, bsd, solaris >> or wherever) and tip of 1.4.x branch, those difference would also >> be interesting. I spent most of my time observing the deltas >> between this new implementation and first bsd followed by linux. > >>From looking at diffs of 1.4.x vs glibc, I've found: > > a) the "/" inside [] thing discussed already
To recap; refer to 2.13.3 bullet 1. within http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03 This behavior is optional, we choose to treat a[x/z]b as two segments, while glibc appears to treat this as a range. Both are correct by spec, and ours is more efficient in that we predetermine the end of segment. We do the same for "\/" within []. > b) glibc does not match the pattern "\/" against "/" with FNM_PATHNAME > set, but APR does: > > 0000000052585e22 apr_fnmatch(".*\//", ".//", 2) = 0, glibc=1 Do we want to change this behavior? We must still be careful of the special meaning of '/' but we can force a mismatch by dropping the logic at line 218-219, which quietly ignores the leading backslash. Other tests for \/ must remain. > c) different interpretation of [ or ] within [] > > 00000001a40dee60 apr_fnmatch("[^[.]", "l", 0) = 0, glibc=1 > 00000003947f62f0 apr_fnmatch("[[.]", ".", 0) = 0, glibc=1 We are correct here, implementations vary... in this case "[."... looks like the introduction to a collating symbol. Stefen and I spent some time on this (w.r.t. character classes) and determined that where [:xxxx:] had broken syntax, we would rewind to the open bracket and treat the '[' as a literal in the list of characters to match. > d) apr does not seem to handle back-slash-escapes inside [] correctly: > > 00000009058acad3 apr_fnmatch(".[\-\z]", ".z", 3) = 1, glibc=0 This is now fixed, I believe we can roll 1.4.5 now when folks are satisfied that all defects are gone. > e) a bunch of weird (invalid?) range specifications: I'm omitting your list for another pass through your tests, now that we have a fix on 1.4 branch (and trunk) to the issue you caught.
