Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Jan 27, 2016 at 1:17 AM, William A Rowe Jr wrote: > > Yann, I didn't pick up our research yet to tweak the SVN implementation, > since we never really tested that. The signed->unsigned transition is a > noop, > so the only question is the fastest way to structure the

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Thu, Jan 21, 2016 at 4:18 PM, William A Rowe Jr wrote: > This is as far as I got on my last iteration, electing what appear > to be 'normal string' handling functions that are part of svn. > > Based on apr's short-name preference, I had yet to redecorate > these functions

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

Sorry, meant to attach something legible... Apache Portable Runtime - Main Page - Related Pages - Modules - Namespaces - Data Structures - Files - Functions <#func-members> C (POSIX locale) string functions String routines Functions apr_array_header_t *

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

I'm assuming that the 'new in 1.6' refers to APR 1.6... In which case, I'm not sure what the Warning for apr_cstr_strtoui64() refers to, version-wise. > On Jan 26, 2016, at 3:58 PM, William A Rowe Jr wrote: > > Sorry, meant to attach something legible... > Apache Portable

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

Also, I see apr_cstr_casecmp() but not a case insensitive version... ?? > On Jan 26, 2016, at 3:58 PM, William A Rowe Jr wrote: > > Sorry, meant to attach something legible... > Apache Portable Runtime > • Main Page > • Related Pages > • Modules > •

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Tue, Jan 26, 2016 at 5:16 PM, Jim Jagielski wrote: > > > On Jan 26, 2016, at 4:39 PM, William A Rowe Jr > wrote: > > > > On Tue, Jan 26, 2016 at 3:12 PM, Jim Jagielski wrote: > > I'm assuming that the 'new in 1.6' refers to APR 1.6...

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

Any updates on this??

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

No time to respond until pressing $dayjob stuff is finished this evening, but I have the entire day tomorrow to devote to bringing the proposed change to trunk/ and proposing for backport to branches/1.6/ On Thu, Jan 21, 2016 at 10:47 AM, Jim Jagielski wrote: > Any updates on

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Thu, Jan 21, 2016 at 4:18 PM, William A Rowe Jr wrote: > > Based on apr's short-name preference, I had yet to redecorate > these functions as apr_cstr_* functions, but that I will get to > tomorrow. If you see something that doesn't fall into the normal > string /

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

This is as far as I got on my last iteration, electing what appear to be 'normal string' handling functions that are part of svn. Based on apr's short-name preference, I had yet to redecorate these functions as apr_cstr_* functions, but that I will get to tomorrow. If you see something that

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

> > On Nov 26, 2015 08:39, "William A Rowe Jr" wrote: > >> Sounds right... Actually a fusion between svn_cstring_* and several >> existing ap_ and apr_ functions would be useful. >> >> SVN folk, any objection to APR appropriating these API's? 20/20 >> hindsight, is

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

I agree that the discussion about the implementation belongs in apr-dev@. Cross posting my original httpd-dev@ message below yours (the wording may be httpd -use case- related, sorry about that)... On Tue, Dec 1, 2015 at 5:31 AM, William A Rowe Jr wrote: > That describes the

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

That describes the 'token' use case, right? While MMX operands let the clib devs play with 16-byte/dword/word units, we are principally looking at very short strings. As soon as you do a 16 byte compare w/delimiting the null byte, your optimization is lost. I think we are of one mind on this,

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

gt;> > >> > Bert >> > >> > From: William A Rowe Jr [mailto:wr...@rowe-clan.net] >> > Sent: woensdag 25 november 2015 22:55 >> > To: httpd <d...@httpd.apache.org> >> > Subject: Re: apr_token_* conclusions (was: Better casecmpstr[n]?) >> > >&

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 9:44 PM, William A Rowe Jr wrote: > LANG="ku_TR.iso88599"; >64 = @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ > ^ @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`ABCDEFGHİJKLMNOPQRSTUVWXYZ{|}~ > v

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Nov 25, 2015 12:00, "Mikhail T." wrote: > > On 25.11.2015 12:42, William A Rowe Jr wrote: >> >> If the script switches setlocale to turkish, for example, our forced-lowercase content-type conversion >> will cause "IMAGE/GIF" to become "ımage/gıf", clearly not what

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 2:06 PM, Jacob Champion wrote: > My two cents: I agree that another "name mangled" abbreviation is not > particularly helpful, but I also agree with Jim's concern: "apr_token" made > me immediately wonder what made this exclusive to HTTP tokens. >

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

In a library that has: apr_pstrdup() apr_pstrndup() apr_pstrmemdup() and apr_pstrmemdup() and apr_pstrndup() are functionally the same, as well as: apr_strnatcasecmp() apr_strnatcmp() neither of which use an 'n' variable to determine string size, yet is

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 3:10 PM, Jim Jagielski wrote: > In a library that has: > > apr_pstrdup() > apr_pstrndup() > apr_pstrmemdup() > which are all semantically and mechanically different... > and apr_pstrmemdup() and apr_pstrndup() are functionally

Re: apr_token_* conclusions (was: Better casecmpstr[n]?)

On Wed, Nov 25, 2015 at 3:55 PM, William A Rowe Jr wrote: > On Wed, Nov 25, 2015 at 3:52 PM, Christophe JAILLET < > christophe.jail...@wanadoo.fr> wrote: > >> Hi, >> >> just in case off, gnome as a set of function g_ascii_... >> (see >>