++1
> On Nov 22, 2015, at 10:33 AM, William A Rowe Jr <[email protected]> wrote:
>
> On Sat, Nov 21, 2015 at 5:10 PM, Eric Covener <[email protected]> wrote:
> On Sat, Nov 21, 2015 at 5:47 PM, William A Rowe Jr <[email protected]>
> wrote:
> > I suggest this is wrong, and that the appropriate table should be built.
> >
> > EBCDIC platforms do have i18n (typicially single-byte) lower/upper
> > equivalences, and the underlying implementation should not be trusted for
> > straight ASCII token case insensitive comparisons.
>
> I don't see it why it shouldn't be trusted, but I've reverted for now,
>
> I'll revisit when this settles down / the function is used somewhere.
>
> Have a look at r1715632 and let me know what you think.
>
> I see a lot of ill-defined or otherwise vague string functions, many of them
> are somewhat duplicate in nature, several of them questionable (unbounded
> recursion, really?) It is probably time to move these all out to
> util_strings.c
> and really evaluate which are appropriate to use in which contexts, while
> others should probably be evicted from trunk. ap_strcmp_match looks like
> the first worst offender (apr_fnmatch is already a much safer implementation.)
>
>
>
