On Wed, Nov 25, 2015 at 3:10 PM, Jim Jagielski <j...@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.
