Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <56573B78.6090504@apache.org>
References: 
 <CACsi253BCKpDOTmShACc3K1KCXeTBb1ugAgaioPXHvDCM+AGiw@mail.gmail.com>
	<9F4E6A21-9544-4F43-834A-F8DCF20693C9@jaguNET.com>
	<CACsi251WHHQtc++VUjU+VmOPmkeJmYZzMFninyGktp36CmS-uw@mail.gmail.com>
	<34DA4EC2-039B-40D5-B176-6E0F8517DC5E@jaguNET.com>
	<CACsi251DTcmki1__9OeBrYrnn_dyrdoo2rL3g6ZspXPx+_nNyg@mail.gmail.com>
	<56562DAF.2080702@wanadoo.fr>
	<CACsi251YLaMUZ1ZGnZBp9brhNNMt6_Bj5vyAeN25rw8-Zq73kA@mail.gmail.com>
	<00ce01d127ce$121901b0$364b0510$@qqmail.nl>
	<BEC946BC-C9CE-47F2-9742-93E1616EF883@jaguNET.com>
	<CACsi251eBQZxjvSfVy32PCDJUcsSKOR1_i0hvfQduoFS4FoYDA@mail.gmail.com>
	<CACsi2513ryPJsgTi9AH9A5aZ8KzK5V-j8_cLePp-8ugncnZLFA@mail.gmail.com>
	<56573B78.6090504@apache.org>
Date: Thu, 26 Nov 2015 15:55:37 -0600
Message-ID: 
 <CACsi253O1DWarmUvg-T99RJsfRDUGqEHngHv7eR1jWU5Yw-oXg@mail.gmail.com>
Subject: Re: apr_token_* conclusions
From: William A Rowe Jr <wrowe@rowe-clan.net>
To: =?UTF-8?Q?Branko_=C4=8Cibej?= <brane@apache.org>
Cc: APR Developer List <dev@apr.apache.org>
Content-Type: multipart/alternative; boundary=001a1140d944903958052578a234

--001a1140d944903958052578a234
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Nov 26, 2015 11:03 AM, "Branko =C4=8Cibej" <brane@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" <wrowe@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 expresse=
s
> >> 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.

--001a1140d944903958052578a234
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On Nov 26, 2015 11:03 AM, &quot;Branko =C4=8Cibej&quot; &lt;=
<a href=3D"mailto:brane@apache.org">brane@apache.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On 26.11.2015 15:44, William A Rowe Jr wrote:<br>
&gt; &gt; Better if I address this Q to svn folks at the APR project :)<br>
&gt; &gt; On Nov 26, 2015 08:39, &quot;William A Rowe Jr&quot; &lt;<a href=
=3D"mailto:wrowe@rowe-clan.net">wrowe@rowe-clan.net</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;&gt; Sounds right... Actually a fusion between svn_cstring_* and s=
everal<br>
&gt; &gt;&gt; existing ap_ and apr_ functions would be useful.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; SVN folk, any objection to APR appropriating these API&#39;s?=
=C2=A0 20/20<br>
&gt; &gt;&gt; hindsight, is apr_cstring_ or shorter apr_cstr_ the way to go=
 here?=C2=A0 You<br>
&gt; &gt;&gt; all had to use the thing so I trust your preferences.=C2=A0 E=
ither expresses<br>
&gt; &gt;&gt; locale C in my mind, so they work for me.<br>
&gt;<br>
&gt; Note that the svn_cstring* functions have *nothing* whatsoever to do<b=
r>
&gt; with the &quot;C&quot; locale; they manipulate nul-terminated &quot;C&=
quot; strings, that&#39;s all.<br>
&gt;<br>
&gt; svn_cstring_casecmp depends on svn_ctype_casecmp; the svn_ctype<br>
&gt; functions are expected to only work on the ASCII subset.<br>
&gt;<br>
&gt; -- Brane</p>
<p dir=3D"ltr">Understood.</p>
<p dir=3D"ltr">Unlike svn we still support EBCDIC and so the use of the phr=
ase &#39;ASCII&#39; is unnecessary confusing.</p>
<p dir=3D"ltr">The aliases C and POSIX both refer to the locale you describ=
e.=C2=A0 Only ASCII digits are recognised, only ASCII punctuation is honore=
d, only ASCII alpha are case-folded.</p>
<p dir=3D"ltr">Or the associated characters in the EBCDIC set.=C2=A0 All ot=
her byte values are opaque.</p>
<p dir=3D"ltr">GCC deemed this important enough to add the g_ascii_str* gcc=
 specific extension functions.</p>
<p dir=3D"ltr">We are saying the same thing and reading, just using differe=
nt semantics to describe cstring.</p>

--001a1140d944903958052578a234--