Glenn, could we get the fnmatch(3) enhancements Ienup Sung from Sun
describes below in libast, too?

Irek

Forwarded conversation
Subject: [i18n-discuss] fnmatch(3C) enhancement [PSARC/2010/318
FastTrack timeout 08/18/2010]
------------------------

From: Ienup Sung <[email protected]>
Date: Thu, Aug 12, 2010 at 2:57 AM
To: [email protected]
Cc: [email protected]



Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates.
All rights reserved.
1. Introduction
   1.1. Project/Component Working Name:
        fnmatch(3C) enhancement
   1.2. Name of Document Author/Supplier:
        Author:  Ienup Sung
   1.3  Date of This Document:
       11 August, 2010
4. Technical Description

OVERVIEW

This case extends fnmatch(3C) to have the support for FNM_CASEFOLD,
FNM_FILE_NAME, FNM_IGNORECASE, and FNM_LEADING_DIR flags as specified in [2].

This is to be more compatible with other platforms such as Linux distros
and BSD variants including MacOS X and FreeBSD.


INTERFACE STABILITY AND RELEASE BINDING

This project imports no notable interfaces. This project exports:

   Interface             Stability     Note
   ---------             ---------     ----
   fnmatch(3C)           Committed     [2]

This project asks for Micro/Patch release binding.


REFERENCES

[1] Related CR:
       6975289 fnmatch library function should support case insensitive
               filename matching.
[2] Updated man page in flat text with change bars indicating the changed
   portions and also corresponding diff file at the materials directory of
   the case:
       fnmatch.3c
       fnmatch.3c.diff

6. Resources and Schedule
   6.4. Steering Committee requested information
       6.4.1. Consolidation C-team Name:
               G11N
   6.5. ARC review type: FastTrack
   6.6. ARC Exposure: open

_______________________________________________
i18n-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/i18n-discuss

----------
From: Nicolas Williams <[email protected]>
Date: Thu, Aug 12, 2010 at 6:14 PM
To: Ienup Sung <[email protected]>
Cc: [email protected]


The description of FNM_LEADING_DIR is confusing:

    FNM_LEADING_DIR   If set, matching is done only until all patterns in    |
                      pattern argument are consumed. Any remaining           |
                      characters at string starting with slash (/)           |
                      are simply ignored and do not affect the matching      |
                      result.                                                |

"matching is done only until all patterns in pattern argument are consumed"
                                ^^^^^^^^^^^^^^^^^^^

I don't know what that means...  The example makes it clear though.  I
would describe it like this:

    FNM_LEADING_DIR   If set, the string matches the pattern if the
                      pattern matches a prefix, ending with slash (/)
                      of the argument string.

The Linux manpage for fnmatch() says:

      FNM_LEADING_DIR
             If  this flag (a GNU extension) is set, the pattern is
             considered to be matched if it matches an initial segment
             of string which is followed by a slash.  This flag is
             mainly for the internal use of glibc and is only
             implemented in certain cases.

The last sentence is not encouraging, but it needn't worry us.

Nico
--

----------
From: Ienup Sung <[email protected]>
Date: Thu, Aug 12, 2010 at 8:07 PM
To: Nicolas Williams <[email protected]>
Cc: [email protected]


Nicolas Williams wrote at 08/12/10 09:14:

The fnmatch(5) that is mentioned at the beginning of the fnmatch(1) man page
explains what "patterns" are.


>                                                                 ... I

The above is also confusing since there is no definition on prefix (including
the scope/range of it).

If the current one is not so clear, I can change that to something like
the following:

    FNM_LEADING_DIR   If set, matching is done with string only until all
                      pattern expressions in pattern argument are
consumed.                       character (/) are simply ignored and
do not affect
                      the matching result.

Ienup
----------
From: Nicolas Williams <[email protected]>
Date: Thu, Aug 12, 2010 at 8:15 PM
To: Ienup Sung <[email protected]>
Cc: [email protected]


Ah, that helps a lot.  Thanks!  You can leave the manpage alone then.

----------
From: Ienup Sung <[email protected]>
Date: Thu, Aug 12, 2010 at 8:22 PM
To: Nicolas Williams <[email protected]>
Cc: [email protected]


Nicolas Williams wrote at 08/12/10 11:15: I think in fact you made a
good point indicating the wording can be
confusing which I agree with you and so I updated the man page as shown in
my previous email. Thank you for your review and comment.

Ienup
----------
From: Sebastien Roy <[email protected]>
Date: Wed, Aug 18, 2010 at 5:11 PM
To: Ienup Sung <[email protected]>
Cc: [email protected], [email protected]


+1

-Seb
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers

Reply via email to