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 (was: Better casecmpstr[n]?)
Date Wed, 25 Nov 2015 21:38:56 GMT
On Wed, Nov 25, 2015 at 3:10 PM, Jim Jagielski <jim@jagunet.com> 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
> the same,


Are you arguing to remove pstrmemdup?  That's a discussion to have
before APR 2.0, certainly, but it isn't functionally the same; bytes within
the copied pstrmemdup may be null, and it has a trailing null appended,
quite different than a memdup.


> as well as:
>
>         apr_strnatcasecmp()
>         apr_strnatcmp()
>
> neither of which use an 'n' variable to determine string
> size,


So there isn't a strnnat[case]cmp() function, are you offering a patch?


> yet is called 'strn...'


Indeed, possible to trip over with grep, for sure, but what is an 'atcmp'?
Seems clear enough to me, but are you proposing a rename?  APR 2.0
is the right time for that...


> whereas the dups use that
> 'n' in 'strndup' to signify that we have a size parameter
>

Indeed... follows the general stdc pattern.


> BUT its functionally equiv function apr_pstrmemdup() is
> called what it is instead of apr_pstrnmemdup()...
>
> ... I think we are WAY overthinking naming here.
>

People may be overthinking, and stumbling to come up with the
most concise and accurate name.  Renaming suggestions and
deprecation of the old names are welcome.  These are good
discussions to have, we made many improvements between
APR 0.9.x and APR 1.0.0 for exactly these reasons.

I agree we can call your proposal apr_str[n]casecmp because it
is a str[n]casecmp implementation - however, that doesn't tell the
user that it is "unusual" but equivalent function that breaks from
posix in that it deliberately chooses not to use the locale and is
primarily for wire protocols.  Thus the _token_ suggestion, but
I am open to other uniqifiers.  I'm not keen on coming up with
a new mishmash of str case len cmp equality blah that will be
harder for reviewers to decipher when reviewing commits.

I know you are in a hurry to just do something, but usually the stuff
we just hurry through many of us regret later, as piles of httpd.h cruft
can attest.  How many headers do you know that contain explicit
sighs?  APR has attempted to be more deliberate in its naming
conventions, by consensus.

You've certainly raised your ire many times at APR's unwillingness
to just modify an API within a major.minor revision, expressed very
little confidence that waiting for an APR release is ever a good idea,
and might be even perceived at hostile toward the entire APR
approach - which has never offered the shoot-from-the-hip approach
that earlier httpd releases enjoyed.  But these decisions were put
down in reaction to frequent breakage for developers prior to httpd 2,
and are in place precisely because APR wants other developers
beyond the world of httpd to have trust and confidence in the API
they are coding to.  Hopefully httpd module authors can enjoy the
same level of confidence.

Mime
View raw message