You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2016/01/21 17:47:03 UTC
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Any updates on this??
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jan 21, 2016 at 4:18 PM, William A Rowe Jr <wr...@rowe-clan.net>
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 / general purpose criteria, feel free to holler before the first
> commit...
>
And yes, I know it doesn't conform yet to our doxygen, one of the
reasons it was delayed until I could finish cleaning that up. The
entire exercise is an svn cp of the sources from subversion so that
we preserve revision history into another home within apr.
Re: apr_token_* conclusions
Posted by Stefan Sperling <st...@apache.org>.
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 strict error checking. I hope this will encourage APR
consumers to routinely check for errors while parsing numbers rather than
trusting input. We did this for SVN and it caught a range of issues from
simple user input problems to detection of integer overflows caused by
repository on-disk corruption.
Note that we do have a special strtol() implementation for performance
critical paths in the repository filesystem code:
^/subversion/trunk/subversion/libsvn_fs_fs/id.c:locale_independent_strtol()
Some parts of the filesystem still use svn_cstring_strtoi64() instead
because they're either not performance critical or require specific
range checks.
Re: apr_token_* conclusions
Posted by Stefan Sperling <st...@apache.org>.
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 strict error checking. I hope this will encourage APR
consumers to routinely check for errors while parsing numbers rather than
trusting input. We did this for SVN and it caught a range of issues from
simple user input problems to detection of integer overflows caused by
repository on-disk corruption.
Note that we do have a special strtol() implementation for performance
critical paths in the repository filesystem code:
^/subversion/trunk/subversion/libsvn_fs_fs/id.c:locale_independent_strtol()
Some parts of the filesystem still use svn_cstring_strtoi64() instead
because they're either not performance critical or require specific
range checks.
Re: apr_token_* conclusions
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Jan 27, 2016 at 10:11 PM, Branko Čibej <br...@apache.org> 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 another) LOL
>
> I guess we're using different meanings of the term 'equivalence group.'
> Doesn't really matter as long as the behaviour is correct. Since we also
> spell 'behaviour' differently, it's not surprising that we're talking
> past each other. Not the same language, y'know; wrong locale. :)
>
No doubt, but I'm certain the Queen and I agree on Jim's and my
interpretation
as stated above. The statement was unambiguously about "case-equivalence"
and the letters A and a are in no way case-equivalent, in any
interpretation of
English nor in any particular locale. Also, I've always failed [American]
English
spelling (I'm equally bad at the Queen's English), as Mike was kind enough
to
point out and correct me earlier today :)
Thankfully there is no s/z ambiguity in the word 'interpretation', LOL!
But we do all seem to all be on the same page, irrespective of locale.
I really want to thank everyone at Subversion who put this code together,
it was very well thought-out. I'd like to figure out how to restore the
pipeline
of svn committer contributions to the core APR libraries, as well as httpd
committer contributions, and all the other downstream consumer developer's
efforts. We have always had a very relaxed committer admission policy,
with a very strict API policy, but it really is not hard to work with.
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'd like to
see more
of this and encourage you all to offer up enhancements. I imagine 1.6 is not
so far away, and with luck and enough contributions, we offer up a 1.7,
even
a 1.8 before we launch the unified apr+apr-util 2.0 sometime this year.
Cheers,
Bill
Re: apr_token_* conclusions
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Jan 27, 2016 at 10:11 PM, Branko Čibej <br...@apache.org> 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 another) LOL
>
> I guess we're using different meanings of the term 'equivalence group.'
> Doesn't really matter as long as the behaviour is correct. Since we also
> spell 'behaviour' differently, it's not surprising that we're talking
> past each other. Not the same language, y'know; wrong locale. :)
>
No doubt, but I'm certain the Queen and I agree on Jim's and my
interpretation
as stated above. The statement was unambiguously about "case-equivalence"
and the letters A and a are in no way case-equivalent, in any
interpretation of
English nor in any particular locale. Also, I've always failed [American]
English
spelling (I'm equally bad at the Queen's English), as Mike was kind enough
to
point out and correct me earlier today :)
Thankfully there is no s/z ambiguity in the word 'interpretation', LOL!
But we do all seem to all be on the same page, irrespective of locale.
I really want to thank everyone at Subversion who put this code together,
it was very well thought-out. I'd like to figure out how to restore the
pipeline
of svn committer contributions to the core APR libraries, as well as httpd
committer contributions, and all the other downstream consumer developer's
efforts. We have always had a very relaxed committer admission policy,
with a very strict API policy, but it really is not hard to work with.
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'd like to
see more
of this and encourage you all to offer up enhancements. I imagine 1.6 is not
so far away, and with luck and enough contributions, we offer up a 1.7,
even
a 1.8 before we launch the unified apr+apr-util 2.0 sometime this year.
Cheers,
Bill
Re: apr_token_* conclusions
Posted by Branko Čibej <br...@apache.org>.
On 27.01.2016 13:29, Jim Jagielski wrote:
>> On Jan 27, 2016, at 4:44 AM, Branko Čibej <br...@apache.org> 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.
>>
>> APR makes no promises about the encoding, but mentioning that these
>> functions are designed to work with the ASCII subset (or EBCDIC
>> equivalent of same) would be quite important, I think?
> I have no idea how encoding matters at all to the meaning
> of case sensitivity... unless, somehow, 'A' and 'a' are
> encoded to the exact same value.
The important part is the bit about "unaccented Latin letters". Without
that clarification, "case-insensitive" in UTF-8 implies that the byte
sequence "\xC7\xBC" compares equal to "\xC7\xBD" (i.e., 'Ǽ' == 'ǽ'),
which is clearly not how that function works; and I'm ignoring fun
issues with Unicode normalization forms.
So yes, encoding does matter.
-- Brane
Re: apr_token_* conclusions
Posted by Branko Čibej <br...@apache.org>.
On 27.01.2016 20:56, William A Rowe Jr wrote:
> On Wed, Jan 27, 2016 at 6:29 AM, Jim Jagielski <jim@jagunet.com
> <ma...@jagunet.com>> wrote:
>
>
> > On Jan 27, 2016, at 4:44 AM, Branko Čibej <brane@apache.org
> <ma...@apache.org>> 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.
> >
> > APR makes no promises about the encoding, but mentioning that these
> > functions are designed to work with the ASCII subset (or EBCDIC
> > equivalent of same) would be quite important, I think?
>
> I have no idea how encoding matters at all to the meaning
> of case sensitivity... unless, somehow, 'A' and 'a' are
> encoded to the exact same value.
>
> In pretty much every description of string and character
> comparison functions I've ever encountered, the terms "case
> sensitive", "case insensitive" or "ignoring case" have all
> been used to describe whether or not the function considers
> the case of the character when doing the comparison. I've
> never seen one use the phrase 'case-equivalent' which implies
> the exact opposite of what it actually does.
>
>
> I committed a fix I like but am still open to edits.
>
> 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 another) LOL
I guess we're using different meanings of the term 'equivalence group.'
Doesn't really matter as long as the behaviour is correct. Since we also
spell 'behaviour' differently, it's not surprising that we're talking
past each other. Not the same language, y'know; wrong locale. :)
-- Brane
Re: apr_token_* conclusions
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Jan 27, 2016 at 6:29 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Jan 27, 2016, at 4:44 AM, Branko Čibej <br...@apache.org> 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.
> >
> > APR makes no promises about the encoding, but mentioning that these
> > functions are designed to work with the ASCII subset (or EBCDIC
> > equivalent of same) would be quite important, I think?
>
> I have no idea how encoding matters at all to the meaning
> of case sensitivity... unless, somehow, 'A' and 'a' are
> encoded to the exact same value.
>
> In pretty much every description of string and character
> comparison functions I've ever encountered, the terms "case
> sensitive", "case insensitive" or "ignoring case" have all
> been used to describe whether or not the function considers
> the case of the character when doing the comparison. I've
> never seen one use the phrase 'case-equivalent' which implies
> the exact opposite of what it actually does.
I committed a fix I like but am still open to edits.
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 another) LOL
Re: apr_token_* conclusions
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 27, 2016, at 4:44 AM, Branko Čibej <br...@apache.org> 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.
>
> APR makes no promises about the encoding, but mentioning that these
> functions are designed to work with the ASCII subset (or EBCDIC
> equivalent of same) would be quite important, I think?
I have no idea how encoding matters at all to the meaning
of case sensitivity... unless, somehow, 'A' and 'a' are
encoded to the exact same value.
In pretty much every description of string and character
comparison functions I've ever encountered, the terms "case
sensitive", "case insensitive" or "ignoring case" have all
been used to describe whether or not the function considers
the case of the character when doing the comparison. I've
never seen one use the phrase 'case-equivalent' which implies
the exact opposite of what it actually does.
Re: apr_token_* conclusions
Posted by Branko Čibej <br...@apache.org>.
On 27.01.2016 01:17, William A Rowe Jr wrote:
> On Tue, Jan 26, 2016 at 5:16 PM, Jim Jagielski <jim@jagunet.com
> <ma...@jagunet.com>> wrote:
>
>
> > On Jan 26, 2016, at 4:39 PM, William A Rowe Jr
> <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
> >
> > On Tue, Jan 26, 2016 at 3:12 PM, Jim Jagielski <jim@jagunet.com
> <ma...@jagunet.com>> wrote:
> > 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.
> >
> > Good catch, trashing the version reference, but keeping the caution.
> >
> >
> > On Tue, Jan 26, 2016 at 3:15 PM, Jim Jagielski <jim@jagunet.com
> <ma...@jagunet.com>> wrote:
> > Also, I see apr_cstr_casecmp() but not a case insensitive
> version... ??
> >
> > casecmp means case-insensitive (c.f. strcasecmp). There is no case-
> > sensitive match, at least not yet. Consider strcmp always just
> works except
> > in a string containing a NULL-octet multibyte continuation
> characters, and
> > we wouldn't speak any such beast in a C/POSIX locale in the
> first place :)
>
> The description sez:
>
> "Compare two strings atr1 and atr2, treating case-equivalent
> unaccented Latin (ASCII subset) letters as equal."
>
> which implies, at least to me, case sensitive. I don't read "case
> equivalent" as case insensitive... equivalence implies "the same"
> to me.
>
>
> Agreed it is very confusing - I had wordsmithed it a bit, but please
> feel free
> to further correct now that it lives on apr trunk (2.0). In fact,
> anyone feel free
> to dive in...
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.
APR makes no promises about the encoding, but mentioning that these
functions are designed to work with the ASCII subset (or EBCDIC
equivalent of same) would be quite important, I think?
-- Brane
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 27, 2016 at 1:17 AM, William A Rowe Jr <wr...@rowe-clan.net> 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 loop. Hopefully
> the
> compiler can do a good job for all architectures. In the svn
> implementation,
> this was through a single character casecmp function/macro that handled
> signed chars, and expanded to an int (which "in theory" is an optimal array
> index, our mileage may vary).
>
> Let's compare performance of this implementation and commit the best
> enhancement.
I'll do some tests with this new implementation.
IIRC, svn_cstring_casecmp() (using svn_ctype_casecmp()) was included
in my latest testing.
It did not perform as well as the current ap_casecmpstr(), but I need
to recheck with these two only now, with latests implementations.
Stay tuned,
Yann.
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, Jan 26, 2016 at 5:16 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> > On Jan 26, 2016, at 4:39 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > On Tue, Jan 26, 2016 at 3:12 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> > 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.
> >
> > Good catch, trashing the version reference, but keeping the caution.
> >
> >
> > On Tue, Jan 26, 2016 at 3:15 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> > Also, I see apr_cstr_casecmp() but not a case insensitive version... ??
> >
> > casecmp means case-insensitive (c.f. strcasecmp). There is no case-
> > sensitive match, at least not yet. Consider strcmp always just works
> except
> > in a string containing a NULL-octet multibyte continuation characters,
> and
> > we wouldn't speak any such beast in a C/POSIX locale in the first place
> :)
>
> The description sez:
>
> "Compare two strings atr1 and atr2, treating case-equivalent unaccented
> Latin (ASCII subset) letters as equal."
>
> which implies, at least to me, case sensitive. I don't read "case
> equivalent" as case insensitive... equivalence implies "the same"
> to me.
>
Agreed it is very confusing - I had wordsmithed it a bit, but please feel
free
to further correct now that it lives on apr trunk (2.0). In fact, anyone
feel free
to dive in...
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 loop. Hopefully
the
compiler can do a good job for all architectures. In the svn
implementation,
this was through a single character casecmp function/macro that handled
signed chars, and expanded to an int (which "in theory" is an optimal array
index, our mileage may vary).
Let's compare performance of this implementation and commit the best
enhancement. Finally have a VC14 environment handy to compare and
contrast the alternatives performance on Windows as well.
Bill
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Posted by Jim Jagielski <ji...@jaguNET.com>.
Also, I see apr_cstr_casecmp() but not a case insensitive version... ??
> On Jan 26, 2016, at 3:58 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Sorry, meant to attach something legible...
> Apache Portable Runtime
> • Main Page
> • Related Pages
> • Modules
> • Namespaces
> • Data Structures
> • Files
>
> Functions
> C (POSIX locale) string functions
> String routines
> Functions
> apr_array_header_t * apr_cstr_split (const char *input, const char *sep_chars, int chop_whitespace, apr_pool_t *pool)
>
> void apr_cstr_split_append (apr_array_header_t *array, const char *input, const char *sep_chars, int chop_whitespace, apr_pool_t *pool)
>
> int apr_cstr_match_glob_list (const char *str, const apr_array_header_t *list)
>
> int apr_cstr_match_list (const char *str, const apr_array_header_t *list)
>
> char * apr_cstr_tokenize (const char *sep, char **str)
>
> int apr_cstr_count_newlines (const char *msg)
>
> char * apr_cstr_join (const apr_array_header_t *strings, const char *separator, apr_pool_t *pool)
>
> int apr_cstr_casecmp (const char *str1, const char *str2)
>
> apr_status_t apr_cstr_strtoi64 (apr_int64_t *n, const char *str, apr_int64_t minval, apr_int64_t maxval, int base)
>
> apr_status_t apr_cstr_atoi64 (apr_int64_t *n, const char *str)
>
> apr_status_t apr_cstr_atoi (int *n, const char *str)
>
> apr_status_t apr_cstr_strtoui64 (apr_uint64_t *n, const char *str, apr_uint64_t minval, apr_uint64_t maxval, int base)
>
> apr_status_t apr_cstr_atoui64 (apr_uint64_t *n, const char *str)
>
> apr_status_t apr_cstr_atoui (unsigned int *n, const char *str)
>
> const char * apr_cstr_skip_prefix (const char *str, const char *prefix)
>
> Detailed Description
>
> The apr_cstr_* functions provide traditional C char * string text handling, and notabilty they treat all text in the C (a.k.a. POSIX) locale using the minimal POSIX character set, represented in either ASCII or a corresponding EBCDIC subset.
>
> Character values outside of that set are treated as opaque bytes, and all multi-byte character sequences are handled as individual distinct octets.
>
> Multi-byte characters sequences whose octets fall in the ASCII range cause unexpected results, such as in the ISO-2022-JP code page where ASCII octets occur within both shift-state and multibyte sequences.
>
> In the case of the UTF-8 encoding, all multibyte characters all fall outside of the C/POSIX range of characters, so these functions are generally safe to use on UTF-8 strings. The programmer must be aware that each octet may not represent a distinct printable character in such encodings.
>
> The standard C99/POSIX string functions, rather than apr_cstr, should be used in all cases where the current locale and encoding of the text is significant.
>
> Function Documentation
>
> apr_status_t apr_cstr_atoi ( int * n,
> const char * str
> )
> Parse the C string str into a 32 bit number, and return it in *n. Assume that the number is represented in base 10. Raise an error if conversion fails (e.g. due to overflow).
>
> The behaviour otherwise is as described for apr_cstr_strtoi64().
>
> Since
> New in 1.6.
> apr_status_t apr_cstr_atoi64 ( apr_int64_t * n,
> const char * str
> )
> Parse the C string str into a 64 bit number, and return it in *n. Assume that the number is represented in base 10. Raise an error if conversion fails (e.g. due to overflow).
>
> The behaviour otherwise is as described for apr_cstr_strtoi64().
>
> Since
> New in 1.6.
> apr_status_t apr_cstr_atoui ( unsigned int * n,
> const char * str
> )
> Parse the C string str into an unsigned 32 bit number, and return it in *n. Assume that the number is represented in base 10. Raise an error if conversion fails (e.g. due to overflow).
>
> The behaviour otherwise is as described for apr_cstr_strtoui64(), including the upper limit of APR_INT64_MAX.
>
> Since
> New in 1.6.
> apr_status_t apr_cstr_atoui64 ( apr_uint64_t * n,
> const char * str
> )
> Parse the C string str into an unsigned 64 bit number, and return it in *n. Assume that the number is represented in base 10. Raise an error if conversion fails (e.g. due to overflow).
>
> The behaviour otherwise is as described for apr_cstr_strtoui64(), including the upper limit of APR_INT64_MAX.
>
> Since
> New in 1.6.
> int apr_cstr_casecmp ( const char * str1,
> const char * str2
> )
> Compare two strings atr1 and atr2, treating case-equivalent unaccented Latin (ASCII subset) letters as equal.
>
> Returns in integer greater than, equal to, or less than 0, according to whether str1 is considered greater than, equal to, or less thanstr2.
>
> Since
> New in 1.6.
> int apr_cstr_count_newlines ( const char * msg )
> Return the number of line breaks in msg, allowing any kind of newline termination (CR, LF, CRLF, or LFCR), even inconsistent.
>
> Since
> New in 1.6.
> char* apr_cstr_join ( const apr_array_header_t * strings,
> const char * separator,
> apr_pool_t * pool
> )
> Return a cstring which is the concatenation of strings (an array of char *) each followed by separator (that is, separator will also end the resulting string). Allocate the result in pool. If strings is empty, then return the empty string.
>
> Since
> New in 1.6.
> int apr_cstr_match_glob_list ( const char * str,
> const apr_array_header_t * list
> )
> Return TRUE iff str matches any of the elements of list, a list of zero or more glob patterns.
>
> int apr_cstr_match_list ( const char * str,
> const apr_array_header_t * list
> )
> Return TRUE iff str exactly matches any of the elements of list.
>
> Since
> new in 1.7
> const char* apr_cstr_skip_prefix ( const char * str,
> const char * prefix
> )
> Skip the common prefix prefix from the C string str, and return a pointer to the next character after the prefix. Return NULL if str does not start with prefix.
>
> Since
> New in 1.6.
> apr_array_header_t* apr_cstr_split ( const char * input,
> const char * sep_chars,
> int chop_whitespace,
> apr_pool_t * pool
> )
> Divide input into substrings, interpreting any char from sep as a token separator.
>
> Return an array of copies of those substrings (plain const char*), allocating both the array and the copies in pool.
>
> None of the elements added to the array contain any of the characters in sep_chars, and none of the new elements are empty (thus, it is possible that the returned array will have length zero).
>
> If chop_whitespace is TRUE, then remove leading and trailing whitespace from the returned strings.
>
> void apr_cstr_split_append ( apr_array_header_t * array,
> const char * input,
> const char * sep_chars,
> int chop_whitespace,
> apr_pool_t * pool
> )
> Like apr_cstr_split(), but append to existing array instead of creating a new one. Allocate the copied substrings in pool (i.e., caller decides whether or not to pass array->pool as pool).
>
> apr_status_t apr_cstr_strtoi64 ( apr_int64_t * n,
> const char * str,
> apr_int64_t minval,
> apr_int64_t maxval,
> int base
> )
> Parse the C string str into a 64 bit number, and return it in *n. Assume that the number is represented in base base. Raise an error if conversion fails (e.g. due to overflow), or if the converted number is smaller than minval or larger than maxval.
>
> Leading whitespace in str is skipped in a locale-dependent way. After that, the string may contain an optional '+' (positive, default) or '-' (negative) character, followed by an optional '0x' prefix if base is 0 or 16, followed by numeric digits appropriate for the base. If there are any more characters after the numeric digits, an error is returned.
>
> If base is zero, then a leading '0x' or '0X' prefix means hexadecimal, else a leading '0' means octal (implemented, though not documented, in apr_strtoi64() in APR 0.9.0 through 1.5.0), else use base ten.
>
> Since
> New in 1.6.
> apr_status_t apr_cstr_strtoui64 ( apr_uint64_t * n,
> const char * str,
> apr_uint64_t minval,
> apr_uint64_t maxval,
> int base
> )
> Parse the C string str into an unsigned 64 bit number, and return it in *n. Assume that the number is represented in base base. Raise an error if conversion fails (e.g. due to overflow), or if the converted number is smaller than minval or larger than maxval.
>
> Leading whitespace in str is skipped in a locale-dependent way. After that, the string may contain an optional '+' (positive, default) or '-' (negative) character, followed by an optional '0x' prefix if base is 0 or 16, followed by numeric digits appropriate for the base. If there are any more characters after the numeric digits, an error is returned.
>
> If base is zero, then a leading '0x' or '0X' prefix means hexadecimal, else a leading '0' means octal (implemented, though not documented, in apr_strtoi64() in APR 0.9.0 through 1.5.0), else use base ten.
>
> Warning
> The implementation used since version 1.7 returns an error if the parsed number is greater than APR_INT64_MAX, even if it is not greater than maxval.
> Since
> New in 1.6.
> char* apr_cstr_tokenize ( const char * sep,
> char ** str
> )
> Get the next token from *str interpreting any char from sep as a token separator. Separators at the beginning of str will be skipped. Returns a pointer to the beginning of the first token in *str or NULL if no token is left. Modifies str such that the next call will return the next token.
>
> Note
> The content of *str may be modified by this function.
> Since
> New in 1.6.
> Generated by 1.8.10
>
> On Tue, Jan 26, 2016 at 2:57 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Thu, Jan 21, 2016 at 4:18 PM, William A Rowe Jr <wr...@rowe-clan.net> 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 as apr_cstr_* functions, but that I will get to
> tomorrow. If you see something that doesn't fall into the normal
> string / general purpose criteria, feel free to holler before the first
> commit...
>
> This is what is going in shortly... we don't have an svn_boolean_t
> so those become int's, while svn_error_t * becomes an apr_status_t.
>
> I'll proceed to commit this full set for scrutiny before digging through
> for the various overlapping functions within apr and even across httpd.
>
>
>
>
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <wr...@rowe-clan.net> wrote:
>
> Sorry, meant to attach something legible...
> Apache Portable Runtime
> • Main Page
> • Related Pages
> • Modules
> • Namespaces
> • Data Structures
> • Files
>
> Functions
> C (POSIX locale) string functions
> String routines
> Functions
> apr_array_header_t * apr_cstr_split (const char *input, const char *sep_chars, int chop_whitespace, apr_pool_t *pool)
>
> void apr_cstr_split_append (apr_array_header_t *array, const char *input, const char *sep_chars, int chop_whitespace, apr_pool_t *pool)
>
> int apr_cstr_match_glob_list (const char *str, const apr_array_header_t *list)
>
> int apr_cstr_match_list (const char *str, const apr_array_header_t *list)
>
> char * apr_cstr_tokenize (const char *sep, char **str)
>
> int apr_cstr_count_newlines (const char *msg)
>
> char * apr_cstr_join (const apr_array_header_t *strings, const char *separator, apr_pool_t *pool)
>
> int apr_cstr_casecmp (const char *str1, const char *str2)
>
> apr_status_t apr_cstr_strtoi64 (apr_int64_t *n, const char *str, apr_int64_t minval, apr_int64_t maxval, int base)
>
> apr_status_t apr_cstr_atoi64 (apr_int64_t *n, const char *str)
>
> apr_status_t apr_cstr_atoi (int *n, const char *str)
>
> apr_status_t apr_cstr_strtoui64 (apr_uint64_t *n, const char *str, apr_uint64_t minval, apr_uint64_t maxval, int base)
>
> apr_status_t apr_cstr_atoui64 (apr_uint64_t *n, const char *str)
>
> apr_status_t apr_cstr_atoui (unsigned int *n, const char *str)
>
> const char * apr_cstr_skip_prefix (const char *str, const char *prefix)
>
> Detailed Description
>
> The apr_cstr_* functions provide traditional C char * string text handling, and notabilty they treat all text in the C (a.k.a. POSIX) locale using the minimal POSIX character set, represented in either ASCII or a corresponding EBCDIC subset.
>
> Character values outside of that set are treated as opaque bytes, and all multi-byte character sequences are handled as individual distinct octets.
>
> Multi-byte characters sequences whose octets fall in the ASCII range cause unexpected results, such as in the ISO-2022-JP code page where ASCII octets occur within both shift-state and multibyte sequences.
>
> In the case of the UTF-8 encoding, all multibyte characters all fall outside of the C/POSIX range of characters, so these functions are generally safe to use on UTF-8 strings. The programmer must be aware that each octet may not represent a distinct printable character in such encodings.
>
> The standard C99/POSIX string functions, rather than apr_cstr, should be used in all cases where the current locale and encoding of the text is significant.
>
> Function Documentation
>
> apr_status_t apr_cstr_atoi ( int * n,
> const char * str
> )
> Parse the C string str into a 32 bit number, and return it in *n. Assume that the number is represented in base 10. Raise an error if conversion fails (e.g. due to overflow).
>
> The behaviour otherwise is as described for apr_cstr_strtoi64().
>
> Since
> New in 1.6.
> apr_status_t apr_cstr_atoi64 ( apr_int64_t * n,
> const char * str
> )
> Parse the C string str into a 64 bit number, and return it in *n. Assume that the number is represented in base 10. Raise an error if conversion fails (e.g. due to overflow).
>
> The behaviour otherwise is as described for apr_cstr_strtoi64().
>
> Since
> New in 1.6.
> apr_status_t apr_cstr_atoui ( unsigned int * n,
> const char * str
> )
> Parse the C string str into an unsigned 32 bit number, and return it in *n. Assume that the number is represented in base 10. Raise an error if conversion fails (e.g. due to overflow).
>
> The behaviour otherwise is as described for apr_cstr_strtoui64(), including the upper limit of APR_INT64_MAX.
>
> Since
> New in 1.6.
> apr_status_t apr_cstr_atoui64 ( apr_uint64_t * n,
> const char * str
> )
> Parse the C string str into an unsigned 64 bit number, and return it in *n. Assume that the number is represented in base 10. Raise an error if conversion fails (e.g. due to overflow).
>
> The behaviour otherwise is as described for apr_cstr_strtoui64(), including the upper limit of APR_INT64_MAX.
>
> Since
> New in 1.6.
> int apr_cstr_casecmp ( const char * str1,
> const char * str2
> )
> Compare two strings atr1 and atr2, treating case-equivalent unaccented Latin (ASCII subset) letters as equal.
>
> Returns in integer greater than, equal to, or less than 0, according to whether str1 is considered greater than, equal to, or less thanstr2.
>
> Since
> New in 1.6.
> int apr_cstr_count_newlines ( const char * msg )
> Return the number of line breaks in msg, allowing any kind of newline termination (CR, LF, CRLF, or LFCR), even inconsistent.
>
> Since
> New in 1.6.
> char* apr_cstr_join ( const apr_array_header_t * strings,
> const char * separator,
> apr_pool_t * pool
> )
> Return a cstring which is the concatenation of strings (an array of char *) each followed by separator (that is, separator will also end the resulting string). Allocate the result in pool. If strings is empty, then return the empty string.
>
> Since
> New in 1.6.
> int apr_cstr_match_glob_list ( const char * str,
> const apr_array_header_t * list
> )
> Return TRUE iff str matches any of the elements of list, a list of zero or more glob patterns.
>
> int apr_cstr_match_list ( const char * str,
> const apr_array_header_t * list
> )
> Return TRUE iff str exactly matches any of the elements of list.
>
> Since
> new in 1.7
> const char* apr_cstr_skip_prefix ( const char * str,
> const char * prefix
> )
> Skip the common prefix prefix from the C string str, and return a pointer to the next character after the prefix. Return NULL if str does not start with prefix.
>
> Since
> New in 1.6.
> apr_array_header_t* apr_cstr_split ( const char * input,
> const char * sep_chars,
> int chop_whitespace,
> apr_pool_t * pool
> )
> Divide input into substrings, interpreting any char from sep as a token separator.
>
> Return an array of copies of those substrings (plain const char*), allocating both the array and the copies in pool.
>
> None of the elements added to the array contain any of the characters in sep_chars, and none of the new elements are empty (thus, it is possible that the returned array will have length zero).
>
> If chop_whitespace is TRUE, then remove leading and trailing whitespace from the returned strings.
>
> void apr_cstr_split_append ( apr_array_header_t * array,
> const char * input,
> const char * sep_chars,
> int chop_whitespace,
> apr_pool_t * pool
> )
> Like apr_cstr_split(), but append to existing array instead of creating a new one. Allocate the copied substrings in pool (i.e., caller decides whether or not to pass array->pool as pool).
>
> apr_status_t apr_cstr_strtoi64 ( apr_int64_t * n,
> const char * str,
> apr_int64_t minval,
> apr_int64_t maxval,
> int base
> )
> Parse the C string str into a 64 bit number, and return it in *n. Assume that the number is represented in base base. Raise an error if conversion fails (e.g. due to overflow), or if the converted number is smaller than minval or larger than maxval.
>
> Leading whitespace in str is skipped in a locale-dependent way. After that, the string may contain an optional '+' (positive, default) or '-' (negative) character, followed by an optional '0x' prefix if base is 0 or 16, followed by numeric digits appropriate for the base. If there are any more characters after the numeric digits, an error is returned.
>
> If base is zero, then a leading '0x' or '0X' prefix means hexadecimal, else a leading '0' means octal (implemented, though not documented, in apr_strtoi64() in APR 0.9.0 through 1.5.0), else use base ten.
>
> Since
> New in 1.6.
> apr_status_t apr_cstr_strtoui64 ( apr_uint64_t * n,
> const char * str,
> apr_uint64_t minval,
> apr_uint64_t maxval,
> int base
> )
> Parse the C string str into an unsigned 64 bit number, and return it in *n. Assume that the number is represented in base base. Raise an error if conversion fails (e.g. due to overflow), or if the converted number is smaller than minval or larger than maxval.
>
> Leading whitespace in str is skipped in a locale-dependent way. After that, the string may contain an optional '+' (positive, default) or '-' (negative) character, followed by an optional '0x' prefix if base is 0 or 16, followed by numeric digits appropriate for the base. If there are any more characters after the numeric digits, an error is returned.
>
> If base is zero, then a leading '0x' or '0X' prefix means hexadecimal, else a leading '0' means octal (implemented, though not documented, in apr_strtoi64() in APR 0.9.0 through 1.5.0), else use base ten.
>
> Warning
> The implementation used since version 1.7 returns an error if the parsed number is greater than APR_INT64_MAX, even if it is not greater than maxval.
> Since
> New in 1.6.
> char* apr_cstr_tokenize ( const char * sep,
> char ** str
> )
> Get the next token from *str interpreting any char from sep as a token separator. Separators at the beginning of str will be skipped. Returns a pointer to the beginning of the first token in *str or NULL if no token is left. Modifies str such that the next call will return the next token.
>
> Note
> The content of *str may be modified by this function.
> Since
> New in 1.6.
> Generated by 1.8.10
>
> On Tue, Jan 26, 2016 at 2:57 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Thu, Jan 21, 2016 at 4:18 PM, William A Rowe Jr <wr...@rowe-clan.net> 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 as apr_cstr_* functions, but that I will get to
> tomorrow. If you see something that doesn't fall into the normal
> string / general purpose criteria, feel free to holler before the first
> commit...
>
> This is what is going in shortly... we don't have an svn_boolean_t
> so those become int's, while svn_error_t * becomes an apr_status_t.
>
> I'll proceed to commit this full set for scrutiny before digging through
> for the various overlapping functions within apr and even across httpd.
>
>
>
>
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Sorry, meant to attach something legible...
Apache Portable Runtime
- Main Page <index.html>
- Related Pages <pages.html>
- Modules <modules.html>
- Namespaces <namespaces.html>
- Data Structures <annotated.html>
- Files <files.html>
-
Functions <#func-members>
C (POSIX locale) string functions
String routines <group__apr__strings.html>
Functions
apr_array_header_t <structapr__array__header__t.html> * apr_cstr_split
<group__apr__cstr.html#ga50b5f39a52d18f3211440602642b5702> (const char
*input, const char *sep_chars, int chop_whitespace, apr_pool_t
<group__apr__pools.html#gaf137f28edcf9a086cd6bc36c20d7cdfb> *pool)
void apr_cstr_split_append
<group__apr__cstr.html#ga380343bfadb7332ece4c042701fa065a> (
apr_array_header_t <structapr__array__header__t.html> *array, const char
*input, const char *sep_chars, int chop_whitespace, apr_pool_t
<group__apr__pools.html#gaf137f28edcf9a086cd6bc36c20d7cdfb> *pool)
int apr_cstr_match_glob_list
<group__apr__cstr.html#ga59052f471fdbe1456fe283f665395be2> (const char
*str, const apr_array_header_t <structapr__array__header__t.html> *list)
int apr_cstr_match_list
<group__apr__cstr.html#ga5884f17dd18202b5dd4388c6664e794b> (const char
*str, const apr_array_header_t <structapr__array__header__t.html> *list)
char * apr_cstr_tokenize
<group__apr__cstr.html#ga43296ec627eefd3d55de5cfb13cc8935> (const char
*sep, char **str)
int apr_cstr_count_newlines
<group__apr__cstr.html#ga6d776750e0b201588e1c24501cd65f71> (const char *msg)
char * apr_cstr_join
<group__apr__cstr.html#ga876441d066aacb75b7320b80ca4d4d29> (const
apr_array_header_t <structapr__array__header__t.html> *strings, const char
*separator, apr_pool_t
<group__apr__pools.html#gaf137f28edcf9a086cd6bc36c20d7cdfb> *pool)
int apr_cstr_casecmp
<group__apr__cstr.html#ga07584e519301a67ff066c30be2785e44> (const char
*str1, const char *str2)
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_strtoi64
<group__apr__cstr.html#ga701ca1217727de647676d41809b5ef90>
(apr_int64_t
*n, const char *str, apr_int64_t minval, apr_int64_t maxval, int base)
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_atoi64
<group__apr__cstr.html#gac22106194f17480bb9d18be39cfed1dd>
(apr_int64_t
*n, const char *str)
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_atoi <group__apr__cstr.html#gad363278febcb4e43ff0affe51a5c8c68> (int
*n, const char *str)
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_strtoui64
<group__apr__cstr.html#ga6398304e57dfb85546234ba9b466ec76> (apr_uint64_t
*n, const char *str, apr_uint64_t minval, apr_uint64_t maxval, int base)
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_atoui64
<group__apr__cstr.html#ga0439b516bc8fd258a9b2c7271fe8347d>
(apr_uint64_t
*n, const char *str)
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_atoui <group__apr__cstr.html#ga4c90f8722d90f833af3e003b9420090d>
(unsigned
int *n, const char *str)
const char * apr_cstr_skip_prefix
<group__apr__cstr.html#ga04e457538985940b16f8759076ca3068> (const char
*str, const char *prefix)
Detailed Description
The apr_cstr_* functions provide traditional C char * string text handling,
and notabilty they treat all text in the C (a.k.a. POSIX) locale using the
minimal POSIX character set, represented in either ASCII or a corresponding
EBCDIC subset.
Character values outside of that set are treated as opaque bytes, and all
multi-byte character sequences are handled as individual distinct octets.
Multi-byte characters sequences whose octets fall in the ASCII range cause
unexpected results, such as in the ISO-2022-JP code page where ASCII octets
occur within both shift-state and multibyte sequences.
In the case of the UTF-8 encoding, all multibyte characters all fall
outside of the C/POSIX range of characters, so these functions are
generally safe to use on UTF-8 strings. The programmer must be aware that
each octet may not represent a distinct printable character in such
encodings.
The standard C99/POSIX string functions, rather than apr_cstr, should be
used in all cases where the current locale and encoding of the text is
significant.
Function Documentation
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_atoi ( int * n,
const char * str
)
Parse the C string *str* into a 32 bit number, and return it in **n*.
Assume that the number is represented in base 10. Raise an error if
conversion fails (e.g. due to overflow).
The behaviour otherwise is as described for apr_cstr_strtoi64()
<group__apr__cstr.html#ga701ca1217727de647676d41809b5ef90>.
SinceNew in 1.6.
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_atoi64 ( apr_int64_t * n,
const char * str
)
Parse the C string *str* into a 64 bit number, and return it in **n*.
Assume that the number is represented in base 10. Raise an error if
conversion fails (e.g. due to overflow).
The behaviour otherwise is as described for apr_cstr_strtoi64()
<group__apr__cstr.html#ga701ca1217727de647676d41809b5ef90>.
SinceNew in 1.6.
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_atoui ( unsigned int * n,
const char * str
)
Parse the C string *str* into an unsigned 32 bit number, and return it in
**n*. Assume that the number is represented in base 10. Raise an error if
conversion fails (e.g. due to overflow).
The behaviour otherwise is as described for apr_cstr_strtoui64()
<group__apr__cstr.html#ga6398304e57dfb85546234ba9b466ec76>, including the
upper limit of APR_INT64_MAX.
SinceNew in 1.6.
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_atoui64 ( apr_uint64_t * n,
const char * str
)
Parse the C string *str* into an unsigned 64 bit number, and return it in
**n*. Assume that the number is represented in base 10. Raise an error if
conversion fails (e.g. due to overflow).
The behaviour otherwise is as described for apr_cstr_strtoui64()
<group__apr__cstr.html#ga6398304e57dfb85546234ba9b466ec76>, including the
upper limit of APR_INT64_MAX.
SinceNew in 1.6.
int apr_cstr_casecmp ( const char * str1,
const char * str2
)
Compare two strings *atr1* and *atr2*, treating case-equivalent unaccented
Latin (ASCII subset) letters as equal.
Returns in integer greater than, equal to, or less than 0, according to
whether *str1* is considered greater than, equal to, or less than*str2*.
SinceNew in 1.6.
int apr_cstr_count_newlines ( const char * msg )
Return the number of line breaks in *msg*, allowing any kind of newline
termination (CR, LF, CRLF, or LFCR), even inconsistent.
SinceNew in 1.6.
char* apr_cstr_join ( const apr_array_header_t
<structapr__array__header__t.html> * strings,
const char * separator,
apr_pool_t <group__apr__pools.html#gaf137f28edcf9a086cd6bc36c20d7cdfb> *
pool
)
Return a cstring which is the concatenation of *strings* (an array of char
*) each followed by *separator* (that is, *separator* will also end the
resulting string). Allocate the result in *pool*. If *strings* is empty,
then return the empty string.
SinceNew in 1.6.
int apr_cstr_match_glob_list ( const char * str,
const apr_array_header_t <structapr__array__header__t.html> * list
)
Return TRUE iff *str* matches any of the elements of *list*, a list of zero
or more glob patterns.
int apr_cstr_match_list ( const char * str,
const apr_array_header_t <structapr__array__header__t.html> * list
)
Return TRUE iff *str* exactly matches any of the elements of *list*.
Sincenew in 1.7
const char* apr_cstr_skip_prefix ( const char * str,
const char * prefix
)
Skip the common prefix *prefix* from the C string *str*, and return a
pointer to the next character after the prefix. Return NULL if *str* does
not start with *prefix*.
SinceNew in 1.6.
apr_array_header_t <structapr__array__header__t.html>* apr_cstr_split ( const
char * input,
const char * sep_chars,
int chop_whitespace,
apr_pool_t <group__apr__pools.html#gaf137f28edcf9a086cd6bc36c20d7cdfb> *
pool
)
Divide *input* into substrings, interpreting any char from *sep* as a token
separator.
Return an array of copies of those substrings (plain const char*),
allocating both the array and the copies in *pool*.
None of the elements added to the array contain any of the characters in
*sep_chars*, and none of the new elements are empty (thus, it is possible
that the returned array will have length zero).
If *chop_whitespace* is TRUE, then remove leading and trailing whitespace
from the returned strings.
void apr_cstr_split_append ( apr_array_header_t
<structapr__array__header__t.html> * array,
const char * input,
const char * sep_chars,
int chop_whitespace,
apr_pool_t <group__apr__pools.html#gaf137f28edcf9a086cd6bc36c20d7cdfb> *
pool
)
Like apr_cstr_split()
<group__apr__cstr.html#ga50b5f39a52d18f3211440602642b5702>, but append to
existing *array* instead of creating a new one. Allocate the copied
substrings in *pool* (i.e., caller decides whether or not to pass
*array->pool* as *pool*).
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_strtoi64 ( apr_int64_t * n,
const char * str,
apr_int64_t minval,
apr_int64_t maxval,
int base
)
Parse the C string *str* into a 64 bit number, and return it in **n*.
Assume that the number is represented in base *base*. Raise an error if
conversion fails (e.g. due to overflow), or if the converted number is
smaller than *minval* or larger than *maxval*.
Leading whitespace in *str* is skipped in a locale-dependent way. After
that, the string may contain an optional '+' (positive, default) or '-'
(negative) character, followed by an optional '0x' prefix if *base* is 0 or
16, followed by numeric digits appropriate for the base. If there are any
more characters after the numeric digits, an error is returned.
If *base* is zero, then a leading '0x' or '0X' prefix means hexadecimal,
else a leading '0' means octal (implemented, though not documented, in
apr_strtoi64() <group__apr__strings.html#ga1da34829609e8976f498b235afd6cbe4> in
APR 0.9.0 through 1.5.0), else use base ten.
SinceNew in 1.6.
apr_status_t <group__apr__errno.html#gaf76ee4543247e9fb3f3546203e590a6c>
apr_cstr_strtoui64 ( apr_uint64_t * n,
const char * str,
apr_uint64_t minval,
apr_uint64_t maxval,
int base
)
Parse the C string *str* into an unsigned 64 bit number, and return it in
**n*. Assume that the number is represented in base *base*. Raise an error
if conversion fails (e.g. due to overflow), or if the converted number is
smaller than *minval* or larger than *maxval*.
Leading whitespace in *str* is skipped in a locale-dependent way. After
that, the string may contain an optional '+' (positive, default) or '-'
(negative) character, followed by an optional '0x' prefix if *base* is 0 or
16, followed by numeric digits appropriate for the base. If there are any
more characters after the numeric digits, an error is returned.
If *base* is zero, then a leading '0x' or '0X' prefix means hexadecimal,
else a leading '0' means octal (implemented, though not documented, in
apr_strtoi64() <group__apr__strings.html#ga1da34829609e8976f498b235afd6cbe4> in
APR 0.9.0 through 1.5.0), else use base ten.
WarningThe implementation used since version 1.7 returns an error if the
parsed number is greater than APR_INT64_MAX, even if it is not greater than
*maxval*.SinceNew in 1.6.
char* apr_cstr_tokenize ( const char * sep,
char ** str
)
Get the next token from **str* interpreting any char from *sep* as a token
separator. Separators at the beginning of *str* will be skipped. Returns a
pointer to the beginning of the first token in **str* or NULL if no token
is left. Modifies *str* such that the next call will return the next token.
NoteThe content of **str* may be modified by this function.SinceNew in 1.6.
------------------------------
Generated by [image: doxygen] <http://www.doxygen.org/index.html>1.8.10
On Tue, Jan 26, 2016 at 2:57 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> On Thu, Jan 21, 2016 at 4:18 PM, William A Rowe Jr <wr...@rowe-clan.net>
> 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 as apr_cstr_* functions, but that I will get to
>> tomorrow. If you see something that doesn't fall into the normal
>> string / general purpose criteria, feel free to holler before the first
>> commit...
>>
>
> This is what is going in shortly... we don't have an svn_boolean_t
> so those become int's, while svn_error_t * becomes an apr_status_t.
>
> I'll proceed to commit this full set for scrutiny before digging through
> for the various overlapping functions within apr and even across httpd.
>
>
>
>
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jan 21, 2016 at 4:18 PM, William A Rowe Jr <wr...@rowe-clan.net>
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 as apr_cstr_* functions, but that I will get to
> tomorrow. If you see something that doesn't fall into the normal
> string / general purpose criteria, feel free to holler before the first
> commit...
>
This is what is going in shortly... we don't have an svn_boolean_t
so those become int's, while svn_error_t * becomes an apr_status_t.
I'll proceed to commit this full set for scrutiny before digging through
for the various overlapping functions within apr and even across httpd.
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 doesn't fall into the normal
string / general purpose criteria, feel free to holler before the first
commit...
Bill
On Thu, Jan 21, 2016 at 4:07 PM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
> 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 <ji...@jagunet.com> wrote:
>
>> Any updates on this??
>>
>
>
Re: apr_token_* conclusions (was: Better casecmpstr[n]?)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <ji...@jagunet.com> wrote:
> Any updates on this??
>