Re: Optimization, modern C and APR 2.0 onwards

2015-11-23 Thread Ruediger Pluem
On 11/20/2015 07:31 PM, William A Rowe Jr wrote: > I'm wondering how the group would react to refactoring some of APR 2.0 > to either offer inline code for many of our heavily consumed functions, > or offering inline + fn implementations alongside one another? > > Would it still be necessary in

Re: Provide our own impl of str[n]casecmp()?

2015-11-23 Thread Branko Čibej
On 21.11.2015 16:39, Yann Ylavic wrote: > On Sat, Nov 21, 2015 at 12:59 PM, Branko Čibej wrote: >> On 21.11.2015 09:31, Graham Leggett wrote: >>> On 21 Nov 2015, at 12:11 AM, William A Rowe Jr wrote: >>> Any objections to picking this up for APR

FW: Unsubscribe

2015-11-23 Thread Nadia
Hello, Can I be unsubscribed to the email chain. Thanks. Yours sincerely, Nadia Majeed (R1442647) Project Specialist Fortress Intelligence Pte Ltd (EA No: 10C4262) 10 Anson Road #34-11 International Plaza Singapore 079903 Tel: (65) 6334 8311 Fax: (65) 6334 8511

Re: Optimization, modern C and APR 2.0 onwards

2015-11-23 Thread William A Rowe Jr
On Mon, Nov 23, 2015 at 1:42 PM, Ruediger Pluem wrote: > > On 11/20/2015 07:31 PM, William A Rowe Jr wrote: > > I'm wondering how the group would react to refactoring some of APR 2.0 > > to either offer inline code for many of our heavily consumed functions, > > or offering

Re: Provide our own impl of str[n]casecmp()?

2015-11-23 Thread William A Rowe Jr
It solves a specific issue that in server apps, conforming to an ASCII derived spec, when not running on the anticipated code page/language context will normalize comparisons in unexpected ways. E.g. I == i, but if the spec is ASCII, then I != ī etc. It was presented as an optimization but my

Re: Provide our own impl of str[n]casecmp()?

2015-11-23 Thread William A Rowe Jr
Sorting ASCII tokens still seems valuable for various sorts of optimizations, and it really doesn't carry a significant cpu cost to do so... I'd rather we kept the <0 ! >0 behavior. On Mon, Nov 23, 2015 at 9:44 AM, Jim Jagielski wrote: > Should we then adjust docs and usage

Re: Provide our own impl of str[n]casecmp()?

2015-11-23 Thread William A Rowe Jr
On Mon, Nov 23, 2015 at 2:11 AM, Branko Čibej wrote: > > +1 to apr_casecmpstr[n]() with a big fat warning in the docstring that > it works for ASCII only. > Well, it 'works' (does not segfault, does not case fold them) for high bit characters, but sorts them in a potentially

Re: Provide our own impl of str[n]casecmp()?

2015-11-23 Thread Jim Jagielski
Should we then adjust docs and usage to remove the "greater/less than" criteria and just say equal strings return 0 and non 0 means that the strings don't compare/are different? > On Nov 23, 2015, at 10:19 AM, William A Rowe Jr wrote: > > On Mon, Nov 23, 2015 at 2:11 AM,