It's for these types of reasons that I suggest that
instead of looking at this as some replacement for
strcasecmp, we instead look at the function on how we
actually *use* it. As far as I know, we simply use
it to see if 2 strings are equal, ignoring ASCII case.
I could be wrong, and I'm sure
On Tue, Nov 24, 2015 at 11:53 AM, Jim Jagielski wrote:
> It's for these types of reasons that I suggest that
> instead of looking at this as some replacement for
> strcasecmp, we instead look at the function on how we
> actually *use* it. As far as I know, we simply use
> it to
On Tue, Nov 24, 2015 at 7:24 PM, William A Rowe Jr wrote:
>
> Well, there is another option, reject API bloat and insist that
> users set LC_ALL="C" if they want httpd to behave correctly
> and performantly.
Which API bloat? If we really want to avoid misleading anybody
At this stage I'm at the point of diminishing returns...
I don't care what color we paint this bike shed.
I'm just glad I was able to come up with something for
people to nit-pick at and get all alpha-male about :P
> On Nov 24, 2015, at 1:24 PM, William A Rowe Jr wrote:
>
On Tue, Nov 24, 2015 at 12:34 PM, Jim Jagielski wrote:
> At this stage I'm at the point of diminishing returns...
>
> I don't care what color we paint this bike shed.
>
> I'm just glad I was able to come up with something for
> people to nit-pick at and get all alpha-male about
On Tue, Nov 24, 2015 at 11:07 AM, William A Rowe Jr wrote:
> Well, we are sorting the entire ASCII so I guess we can drop "for
> alpha-numerics only".
Maybe it was fixed and I missed it, but didn't you point
out that [] were not sorted right relative to alphas per
POSIX
On Tue, Nov 24, 2015 at 10:11 AM, Eric Covener wrote:
> On Tue, Nov 24, 2015 at 11:07 AM, William A Rowe Jr
> wrote:
> > Well, we are sorting the entire ASCII so I guess we can drop "for
> > alpha-numerics only".
>
> Maybe it was fixed and I missed it,
On Tue, Nov 24, 2015 at 6:35 AM, Jim Jagielski wrote:
> Yeah, but not, afaict, EBCDIC.
It would help for you to review the sources. It wasn't a correct alpha sort
until I put in the EBCDIC code table this weekend, now EBCDIC chars
collate in ASCII order under this function.
if the current EBCDIC validates the >< lex, then by all means
update the docs to reflect that. You specifically said that
"The implementation does provide ASCII numeric-alpha ordering."
The main reason I was suggesting this was that, really,
it would make sense for the function to return true if
Yeah, but not, afaict, EBCDIC. And in our use case, we
don't care (and never use) the greater/less-than functionality,
just the equal to. This allows for possible other improvements/
enhancements which might "break" the >< but doesn't affect
how *we* use it.
> On Nov 23, 2015, at 12:01 PM, William
On Tue, Nov 24, 2015 at 9:28 AM, Jim Jagielski wrote:
> if the current EBCDIC validates the >< lex, then by all means
> update the docs to reflect that. You specifically said that
> "The implementation does provide ASCII numeric-alpha ordering."
>
You are right, calling out
On Tue, Nov 24, 2015 at 10:41 AM, William A Rowe Jr wrote:
> You are right, calling out "This implementation provides ASCII-ordering
> of strings (EBCDIC text is also ASCII ordered on those platforms)"
> might have been clearer? Eric, what phrasing would make sense to you
>
On Tue, Nov 24, 2015 at 9:46 AM, Eric Covener wrote:
> On Tue, Nov 24, 2015 at 10:41 AM, William A Rowe Jr
> wrote:
> > You are right, calling out "This implementation provides ASCII-ordering
> > of strings (EBCDIC text is also ASCII ordered on those
On Mon, Nov 23, 2015 at 9:58 AM, wrote:
> Author: jim
> Date: Mon Nov 23 15:58:25 2015
> New Revision: 1715859
>
> URL: http://svn.apache.org/viewvc?rev=1715859=rev
> Log:
> we just worry about "equality" with this implementation...
> So it's not a "real" strcasecmp replacement.
14 matches
Mail list logo