On 12.04.2011 21:37, William A. Rowe Jr. wrote:
> On 4/12/2011 11:56 AM, Jeff Trawick wrote:
>> On Tue, Apr 12, 2011 at 12:29 PM, William A. Rowe Jr.
>> wrote:
>>> I have one dev question for my apr_fnmatch() refactoring
>>>
>>> Today we lowercase the two characters (and don't support case-insensi
On 4/12/2011 2:46 PM, Bert Huijben wrote:
> And Turkish has the same problem the other way around. (the German
> example is not in the normal 7 bit ascii, while the Turkish 'I' is)
Thanks!
It might be OK in the end, since there is no possible upper/lower match.
tolower(c)/toupper(c) should be ret
On 4/12/2011 11:56 AM, Jeff Trawick wrote:
> On Tue, Apr 12, 2011 at 12:29 PM, William A. Rowe Jr.
> wrote:
>> I have one dev question for my apr_fnmatch() refactoring
>>
>> Today we lowercase the two characters (and don't support case-insensitive
>> range matches at all, I won't change this apr-s
On Tue, Apr 12, 2011 at 12:29 PM, William A. Rowe Jr.
wrote:
> I have one dev question for my apr_fnmatch() refactoring
>
> Today we lowercase the two characters (and don't support case-insensitive
> range matches at all, I won't change this apr-specific quirk). But IIRC
> there are language with
I have one dev question for my apr_fnmatch() refactoring
Today we lowercase the two characters (and don't support case-insensitive
range matches at all, I won't change this apr-specific quirk). But IIRC
there are language with multiple lower case representations of the same
upper case character,
