You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Branko Čibej <br...@apache.org> on 2015/11/26 18:03:52 UTC
Re: apr_token_* conclusions
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" <wr...@rowe-clan.net> 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 apr_cstring_ or shorter apr_cstr_ the way to go here? You
>> all had to use the thing so I trust your preferences. Either expresses
>> locale C in my mind, so they work for me.
Note that the svn_cstring* functions have *nothing* whatsoever to do
with the "C" locale; they manipulate nul-terminated "C" strings, that's all.
svn_cstring_casecmp depends on svn_ctype_casecmp; the svn_ctype
functions are expected to only work on the ASCII subset.
-- Brane
>> On Nov 26, 2015 07:38, "Jim Jagielski" <ji...@jagunet.com> wrote:
>>
>>> Yeah, SVN's 'svn_cstring_casecmp' and how it's used is
>>> pretty much inline with my thoughts on how httpd would
>>> use ours...
>>>
>>>> On Nov 25, 2015, at 5:10 PM, Bert Huijben <be...@qqmail.nl> wrote:
>>>>
>>>> We have a set of similar comparison functions in Subversion. I’m pretty
>>> sure we already had these in the time we still had ebcdic support on trunk.
>>>> (We removed that support years ago, but the code should still live on a
>>> branch)
>>>> Bert
>>>>
>>>> From: William A Rowe Jr [mailto:wrowe@rowe-clan.net]
>>>> Sent: woensdag 25 november 2015 22:55
>>>> To: httpd <de...@httpd.apache.org>
>>>> Subject: Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
>>>>
>>>> On Wed, Nov 25, 2015 at 3:52 PM, Christophe JAILLET <
>>> christophe.jaillet@wanadoo.fr> wrote:
>>>>> Hi,
>>>>>
>>>>> just in case off, gnome as a set of function g_ascii_...
>>>>> (see
>>> https://developer.gnome.org/glib/2.28/glib-String-Utility-Functions.html#g-ascii-strcasecmp
>>> )
>>>> Interesting, does anyone know offhand whether these perform the expected
>>>> or the stated behavior under EBCDIC environments?
>>>
Re: apr_token_* conclusions
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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*&t and just code some cool stuff? If you are on that page,
quit apologizing. If you are out to score some cool public posts, it might
be time to hang up that hat. And it isn't specific to Jim, anyone who
complains that APR moves too slow wasn't hanging around here 12 yrs ago,
the moment it is time for a release, there will be the momentum for release.
Grow up everyone, this isn't httpd. Let's code.
On Nov 30, 2015 06:15, "Jim Jagielski" <ji...@jagunet.com> wrote:
>
> > On Nov 27, 2015, at 2:15 PM, Branko Čibej <br...@apache.org> wrote:
> >
> > On 27.11.2015 15:59, Jim Jagielski wrote:
> >>> On Nov 26, 2015, at 8:49 PM, Branko Čibej <br...@apache.org> 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 could "donate"; we just never really got
> >>> around to producing the necessary patches.
> >> Yeah, svn is in the same situation as httpd. There are
> >> some functions would "ideally" would exist in APR,
> >> but APR doesn't move "fast enough" to allow that to
> >> happen, so both projects start collecting APR-like
> >> kruft after awhile...
> >>
> >> It certainly would be nice if there was someway to address
> >> that...
> >
> > Uh, what I wrote is in no way intended to be a criticism of APR. Maybe
> > if people who think APR isn't moving fast enough spent their time
> > writing code here instead of writing mails about it, this "problem"
> > would just vanish. At least, that's my understanding of how open source
> > is supposed to work -- right, Jim? ;)
>
> Gosh! You are right! Gee whiz, I haven't had any substantial code added
> to APR since 1.5.1. Thanks for reminding me! I really feel completely
> and utterly unworthy to comment on or criticize APR in any meaningful
> way and I offer my heartfelt apologies to everyone on this thread
> for wasting their time on a thread which started off as a suggestion
> for a new function to be added to httpd but, I noted:
>
> I propose a ap_strncasecmp/ap_strcasecmp which we should use.
> Ideally, it would be in apr but no need to wait for that
> to happen :)
>
> which, at least how I read it, implies code to be added to APR
> in the ideal case. But that is besides the point, as Brane so
> correctly says! Instead of writing emails about code to be
> added, we should instead be writing the code itself, which,
> of course, will be accepted in as-is with no discussion whatsoever,
> since, heck, that's kind of what's going on here, but as Brane
> reminds us all, such a thing is a problem that will magically
> disappear the more we write code!
>
> I propose that no message be allowed on the dev@apr list unless
> a 15-line patch or code contribution is attached. This will
> solve the nasty problem! In fact, maybe we should just shut down
> dev@apr since it encourages such unconstructive behavior as "writing
> emails" when we instead should be head's down cranking out code
> that may, or may not (usually not) be added and used before the
> end of the decade.
Re: apr_token_* conclusions
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 27, 2015, at 2:15 PM, Branko Čibej <br...@apache.org> wrote:
>
> On 27.11.2015 15:59, Jim Jagielski wrote:
>>> On Nov 26, 2015, at 8:49 PM, Branko Čibej <br...@apache.org> 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 could "donate"; we just never really got
>>> around to producing the necessary patches.
>> Yeah, svn is in the same situation as httpd. There are
>> some functions would "ideally" would exist in APR,
>> but APR doesn't move "fast enough" to allow that to
>> happen, so both projects start collecting APR-like
>> kruft after awhile...
>>
>> It certainly would be nice if there was someway to address
>> that...
>
> Uh, what I wrote is in no way intended to be a criticism of APR. Maybe
> if people who think APR isn't moving fast enough spent their time
> writing code here instead of writing mails about it, this "problem"
> would just vanish. At least, that's my understanding of how open source
> is supposed to work -- right, Jim? ;)
Gosh! You are right! Gee whiz, I haven't had any substantial code added
to APR since 1.5.1. Thanks for reminding me! I really feel completely
and utterly unworthy to comment on or criticize APR in any meaningful
way and I offer my heartfelt apologies to everyone on this thread
for wasting their time on a thread which started off as a suggestion
for a new function to be added to httpd but, I noted:
I propose a ap_strncasecmp/ap_strcasecmp which we should use.
Ideally, it would be in apr but no need to wait for that
to happen :)
which, at least how I read it, implies code to be added to APR
in the ideal case. But that is besides the point, as Brane so
correctly says! Instead of writing emails about code to be
added, we should instead be writing the code itself, which,
of course, will be accepted in as-is with no discussion whatsoever,
since, heck, that's kind of what's going on here, but as Brane
reminds us all, such a thing is a problem that will magically
disappear the more we write code!
I propose that no message be allowed on the dev@apr list unless
a 15-line patch or code contribution is attached. This will
solve the nasty problem! In fact, maybe we should just shut down
dev@apr since it encourages such unconstructive behavior as "writing
emails" when we instead should be head's down cranking out code
that may, or may not (usually not) be added and used before the
end of the decade.
Re: apr_token_* conclusions
Posted by Branko Čibej <br...@apache.org>.
On 27.11.2015 15:59, Jim Jagielski wrote:
>> On Nov 26, 2015, at 8:49 PM, Branko Čibej <br...@apache.org> 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 could "donate"; we just never really got
>> around to producing the necessary patches.
> Yeah, svn is in the same situation as httpd. There are
> some functions would "ideally" would exist in APR,
> but APR doesn't move "fast enough" to allow that to
> happen, so both projects start collecting APR-like
> kruft after awhile...
>
> It certainly would be nice if there was someway to address
> that...
Uh, what I wrote is in no way intended to be a criticism of APR. Maybe
if people who think APR isn't moving fast enough spent their time
writing code here instead of writing mails about it, this "problem"
would just vanish. At least, that's my understanding of how open source
is supposed to work -- right, Jim? ;)
-- Brane
Re: apr_token_* conclusions
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 26, 2015, at 8:49 PM, Branko Čibej <br...@apache.org> 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 could "donate"; we just never really got
> around to producing the necessary patches.
Yeah, svn is in the same situation as httpd. There are
some functions would "ideally" would exist in APR,
but APR doesn't move "fast enough" to allow that to
happen, so both projects start collecting APR-like
kruft after awhile...
It certainly would be nice if there was someway to address
that...
Re: apr_token_* conclusions
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Nov 26, 2015 at 7:49 PM, Branko Čibej <br...@apache.org> wrote:
> On 26.11.2015 22:55, William A Rowe Jr wrote:
> > On Nov 26, 2015 11:03 AM, "Branko Čibej" <br...@apache.org> 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" <wr...@rowe-clan.net>
> 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 apr_cstring_ or shorter apr_cstr_ the way to go here?
> > You
> >>>> all had to use the thing so I trust your preferences. Either
> expresses
> >>>> locale C in my mind, so they work for me.
> >> Note that the svn_cstring* functions have *nothing* whatsoever to do
> >> with the "C" locale; they manipulate nul-terminated "C" strings, that's
> > all.
> >> svn_cstring_casecmp depends on svn_ctype_casecmp; the svn_ctype
> >> functions are expected to only work on the ASCII subset.
> >>
> >> -- Brane
> > Understood.
> >
> > Unlike svn we still support EBCDIC and so the use of the phrase 'ASCII'
> is
> > unnecessary confusing.
> >
> > The aliases C and POSIX both refer to the locale you describe. Only
> ASCII
> > digits are recognised, only ASCII punctuation is honored, only ASCII
> alpha
> > are case-folded.
> >
> > Or the associated characters in the EBCDIC set. All other byte values
> are
> > opaque.
> >
> > GCC deemed this important enough to add the g_ascii_str* gcc specific
> > extension functions.
> >
> > We are saying the same thing and reading, just using different semantics
> to
> > describe cstring.
>
> Well, not exactly; the svn_cstring_casecmp is the only function in that
> group that works as if it were always in the "C" locale. The others are
> are simply a convenience for managing variable-length nul-terminated
> strings. In Subversion, for example, their contents are usually encoded
> in UTF-8.
>
To clarify, in the "C" locale, utf-8 is just fine. Do the other functions
treat
the opaque utf-8 high-bit-set characters specifically, or do they simply
treat them as individual distinct bytes?
If it is the later, that conforms to the C/POSIX locale, but if they are
actually
handled explicitly as utf-8 sequences, that gets a little more tricky.
> ASCII vs. EBCDIC (or any other single-byte encoding) is really only a
> matter of using different case folding and codepoint attribute tables
> (or equivalents; there's no reason the implementations have to be
> table-driven). More complex encodings are pretty much out of scope, IMO.
>
And we agree from an httpd perspective. The issue is that we must handle
all ASCII (RFC-defined) sequences specifically and have no side-effects
that we weren't expecting, from a hardening perspective.
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 could "donate"; we just never really got
> around to producing the necessary patches.
>
I hope as we start discussing 2.0 in more detail, that some of these come
through. But I'm inclined not to wait and to begin forking this specific
API
as something that httpd 2.next needs, and some future version of 2.4.x may
decide it must adopt.
Thanks for the insights,
Bill
Re: apr_token_* conclusions
Posted by Branko Čibej <br...@apache.org>.
On 26.11.2015 22:55, William A Rowe Jr wrote:
> On Nov 26, 2015 11:03 AM, "Branko Čibej" <br...@apache.org> 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" <wr...@rowe-clan.net> 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 apr_cstring_ or shorter apr_cstr_ the way to go here?
> You
>>>> all had to use the thing so I trust your preferences. Either expresses
>>>> locale C in my mind, so they work for me.
>> Note that the svn_cstring* functions have *nothing* whatsoever to do
>> with the "C" locale; they manipulate nul-terminated "C" strings, that's
> all.
>> svn_cstring_casecmp depends on svn_ctype_casecmp; the svn_ctype
>> functions are expected to only work on the ASCII subset.
>>
>> -- Brane
> Understood.
>
> Unlike svn we still support EBCDIC and so the use of the phrase 'ASCII' is
> unnecessary confusing.
>
> The aliases C and POSIX both refer to the locale you describe. Only ASCII
> digits are recognised, only ASCII punctuation is honored, only ASCII alpha
> are case-folded.
>
> Or the associated characters in the EBCDIC set. All other byte values are
> opaque.
>
> GCC deemed this important enough to add the g_ascii_str* gcc specific
> extension functions.
>
> We are saying the same thing and reading, just using different semantics to
> describe cstring.
Well, not exactly; the svn_cstring_casecmp is the only function in that
group that works as if it were always in the "C" locale. The others are
are simply a convenience for managing variable-length nul-terminated
strings. In Subversion, for example, their contents are usually encoded
in UTF-8.
ASCII vs. EBCDIC (or any other single-byte encoding) is really only a
matter of using different case folding and codepoint attribute tables
(or equivalents; there's no reason the implementations have to be
table-driven). More complex encodings are pretty much out of scope, IMO.
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 could "donate"; we just never really got
around to producing the necessary patches.
-- Brane
Re: apr_token_* conclusions
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Nov 26, 2015 11:03 AM, "Branko Čibej" <br...@apache.org> 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" <wr...@rowe-clan.net> 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 apr_cstring_ or shorter apr_cstr_ the way to go here?
You
> >> all had to use the thing so I trust your preferences. Either expresses
> >> locale C in my mind, so they work for me.
>
> Note that the svn_cstring* functions have *nothing* whatsoever to do
> with the "C" locale; they manipulate nul-terminated "C" strings, that's
all.
>
> svn_cstring_casecmp depends on svn_ctype_casecmp; the svn_ctype
> functions are expected to only work on the ASCII subset.
>
> -- Brane
Understood.
Unlike svn we still support EBCDIC and so the use of the phrase 'ASCII' is
unnecessary confusing.
The aliases C and POSIX both refer to the locale you describe. Only ASCII
digits are recognised, only ASCII punctuation is honored, only ASCII alpha
are case-folded.
Or the associated characters in the EBCDIC set. All other byte values are
opaque.
GCC deemed this important enough to add the g_ascii_str* gcc specific
extension functions.
We are saying the same thing and reading, just using different semantics to
describe cstring.