apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: apr_token_* conclusions
Date Thu, 26 Nov 2015 21:55:37 GMT
On Nov 26, 2015 11:03 AM, "Branko ─îibej" <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 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.

Mime
View raw message