Re: apr_token_* conclusions

On 27.01.2016 20:56, William A Rowe Jr wrote: > On Wed, Jan 27, 2016 at 6:29 AM, Jim Jagielski > wrote: > > > > On Jan 27, 2016, at 4:44 AM, Branko Čibej > wrote: > > > > > > Hmph, it's

Re: apr_token_* conclusions

On 27.01.2016 13:29, Jim Jagielski wrote: >> On Jan 27, 2016, at 4:44 AM, Branko Čibej wrote: >> >> >> Hmph, it's concise, not confusing. Subversion's APIs expect all strings >> to be encoded in UTF-8, so the docstring can't just say >> "case-insensitive" because that would be

Re: apr_token_* conclusions

On Wed, Jan 27, 2016 at 10:11 PM, Branko Čibej wrote: > > > > Stating that equivalent-case are treated as equal states that the > > code points "A"-"Z" are all treated as equal, and "a"-"z" are all > > treated as equal (and "A" and "a" would be treated as unique > > of one

Re: apr_token_* conclusions

On Wed, Jan 27, 2016 at 10:40:06PM -0600, William A Rowe Jr wrote: > If you are new to the conversation, include/apr_cstr.h has absorbed much of > the efforts of svn_cstring_* API's into apr_cstr_* functions. I'm very happy to see our strtol()-wrappers in APR. These wrap the POSIX functions with

Re: apr_token_* conclusions

On Wed, Jan 27, 2016 at 6:29 AM, Jim Jagielski wrote: > > > On Jan 27, 2016, at 4:44 AM, Branko Čibej wrote: > > > > > > Hmph, it's concise, not confusing. Subversion's APIs expect all strings > > to be encoded in UTF-8, so the docstring can't just say > >

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

> On Jan 27, 2016, at 4:44 AM, Branko Čibej wrote: > > > Hmph, it's concise, not confusing. Subversion's APIs expect all strings > to be encoded in UTF-8, so the docstring can't just say > "case-insensitive" because that would be extremely misleading in that > context. > >

Re: apr_token_* conclusions

On 27.01.2016 01:17, William A Rowe Jr wrote: > 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,

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

The only question in my mind, after thinking about this all day, is how do we (plural) de-escalate this immature behaviour between senior ASF members? If there was a time to fall on your own katana James, that most recent post was it. Let's cut the s* and just code some cool stuff? If you are

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

On 01.12.2015 05:31, William A Rowe Jr wrote: > > 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

Re: apr_token_* conclusions

> On Nov 27, 2015, at 2:15 PM, Branko Čibej wrote: > > On 27.11.2015 15:59, Jim Jagielski wrote: >>> On Nov 26, 2015, at 8:49 PM, Branko Čibej wrote: >>> >>> In any case — I don't think anyone over at dev@s.a.o would object to APR >>> including those

Re: apr_token_* conclusions

On 27.11.2015 15:59, Jim Jagielski wrote: >> On Nov 26, 2015, at 8:49 PM, Branko Čibej wrote: >> >> In any case — I don't think anyone over at dev@s.a.o would object to APR >> including those functions. We actually have a number of other, heh, >> improvements on APR that we

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

nk. >>>> (We removed that support years ago, but the code should still live on a >>> branch) >>>> Bert >>>> >>>> From: William A Rowe Jr [mailto:wr...@rowe-clan.net] >>>> Sent: woensdag 25 november 2015 22:55 >>>> To:

Re: apr_token_* conclusions

On Nov 26, 2015 11:03 AM, "Branko Čibej" wrote: > > On 26.11.2015 15:44, William A Rowe Jr wrote: > > Better if I address this Q to svn folks at the APR project :) > > On Nov 26, 2015 08:39, "William A Rowe Jr" wrote: > > > >> Sounds right... Actually a

Re: apr_token_* conclusions

On 26.11.2015 22:55, William A Rowe Jr wrote: > On Nov 26, 2015 11:03 AM, "Branko Čibej" wrote: >> On 26.11.2015 15:44, William A Rowe Jr wrote: >>> Better if I address this Q to svn folks at the APR project :) >>> On Nov 26, 2015 08:39, "William A Rowe Jr"

Re: apr_token_* conclusions

On Thu, Nov 26, 2015 at 7:49 PM, Branko Čibej wrote: > On 26.11.2015 22:55, William A Rowe Jr wrote: > > On Nov 26, 2015 11:03 AM, "Branko Čibej" wrote: > >> On 26.11.2015 15:44, William A Rowe Jr wrote: > >>> Better if I address this Q to svn folks at the

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

Some further analysis... -- Forwarded message -- From: William A Rowe Jr <wr...@rowe-clan.net> Date: Wed, Nov 25, 2015 at 9:44 PM Subject: Re: apr_token_* conclusions (was: Better casecmpstr[n]?) To: httpd <d...@httpd.apache.org> On Wed, Nov 25, 2015 at 6:45 PM, Wi

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 >>

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

tl;dr - feel free to skip "httpd" specifics to get to the meat of the APR discussion items. -- Forwarded message -- From: William A Rowe Jr <wr...@rowe-clan.net> Date: Wed, Nov 25, 2015 at 11:42 AM Subject: apr_token_* conclusions (was: Better casecmpstr[n