Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0A79F18FCA for ; Wed, 25 Nov 2015 21:39:11 +0000 (UTC) Received: (qmail 82020 invoked by uid 500); 25 Nov 2015 21:39:10 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 81938 invoked by uid 500); 25 Nov 2015 21:39:10 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 81928 invoked by uid 99); 25 Nov 2015 21:39:10 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Nov 2015 21:39:10 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 2A8841A2A9B for ; Wed, 25 Nov 2015 21:39:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=3, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=rowe-clan-net.20150623.gappssmtp.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id yvNVdJfMyPts for ; Wed, 25 Nov 2015 21:38:58 +0000 (UTC) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 2EC092059D for ; Wed, 25 Nov 2015 21:38:57 +0000 (UTC) Received: by iofh3 with SMTP id h3so66763226iof.3 for ; Wed, 25 Nov 2015 13:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowe-clan-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dLB4ORPCD1AauFCAwou/dBTh4oNzDggTM+91f5v84VA=; b=APys1cF4pXwBNx42goX2P+Ilr6QdVRcp1K3njvQ4AMQ6/iUkhXA/MUSjab1oDfbRL9 mmsW0ifZBRoIdMXaex7notTV3AiV+kMEVBoi7fdL9oDzFu1CtwuEbVbBB0KU4fm9h2qv TPteP9RqUU6Wu/ezANtqYFojCNYQ2xzoQBqpgyHmPq/BCLO3maaM4n2eSj5slTxf/N4z oWQSKC5KiIVT/2zGE1/uFI+exUQk37c4bQMURnNeVcJ37rU7lnWCF0/19MZoWRxaFvna HGhdgLqMha6xpjTKbLsbsNHumAQk8N8Hbmj7Q+wbxPtoHQJZ26RcAGF/p5gM9TV79YCs UWdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dLB4ORPCD1AauFCAwou/dBTh4oNzDggTM+91f5v84VA=; b=gFIoLDVeIVNnfxS5cLbjefRLC9sMgr2J+JXhtM+cyaTX25Db7CGHXnefNV2ROZ9kr3 vJmK7zyu4xF1398j/N+JhnWxGMbKV2WvSorXPZEc6meDUlOJoeitPmRihdh+4NWaT6HG Dn3wZ8AULMRVOZ+Zb7FSqjvo7srMdMaHGdz5wamkQtwLe5mjs8wg93Z92h06iop+RzZs hlJRr02jBDLZxqSh0GCNgZS13Jz6KQyLnawLw8BTOv78lWPHHo+aaWtqNUzjDnjLOvcf rfeajaCzH3Z3b77YP1SP1xEH19rrJqIRUoQBE0K7K0qEhwc6LbO+rK4rUhv/WkhiKl0K /97w== X-Gm-Message-State: ALoCoQnsQvTZLWWFS+KN+ansOETCwtWZP3hC2OncFatFwvSVrfb56BEUKKIX/chA68NFOUA8aPSk MIME-Version: 1.0 X-Received: by 10.107.156.6 with SMTP id f6mr3118469ioe.163.1448487536087; Wed, 25 Nov 2015 13:38:56 -0800 (PST) Received: by 10.107.62.136 with HTTP; Wed, 25 Nov 2015 13:38:56 -0800 (PST) In-Reply-To: <38935ED2-E3F5-48BA-AC25-DB20DE66F95D@jaguNET.com> References: <9F4E6A21-9544-4F43-834A-F8DCF20693C9@jaguNET.com> <34DA4EC2-039B-40D5-B176-6E0F8517DC5E@jaguNET.com> <38935ED2-E3F5-48BA-AC25-DB20DE66F95D@jaguNET.com> Date: Wed, 25 Nov 2015 15:38:56 -0600 Message-ID: Subject: Re: apr_token_* conclusions (was: Better casecmpstr[n]?) From: William A Rowe Jr To: httpd , APR Developer List Content-Type: multipart/alternative; boundary=001a1140ccc00cf7220525644952 --001a1140ccc00cf7220525644952 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 25, 2015 at 3:10 PM, Jim Jagielski 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. --001a1140ccc00cf7220525644952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 25, 2015 at 3:10 PM, Jim Jagielski <jim@jagunet.com> w= rote:
In a library that has:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 apr_pstrdup()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 apr_pstrndup()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 apr_pstrmemdup()

which are all semantically and mechanically different...
= =C2=A0
and apr_pstrmemdup() and apr_pstrndup() are functionally
the same,

Are you arguing to remove pstrme= mdup?=C2=A0 That's a discussion to have
before APR 2.0, certa= inly, but it isn't functionally the same; bytes within
the co= pied pstrmemdup may be null, and it has a trailing null appended,
quite different than a memdup.
=C2=A0
as well as:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 apr_strnatcasecmp()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 apr_strnatcmp()

neither of which use an 'n' variable to determine string
size,

So there isn't a strnnat[case]cm= p() function, are you offering a patch?
=C2=A0
yet is called 'strn...'

Indeed, possible to trip over with grep, for sure, but what is an &= #39;atcmp'?
Seems clear enough to me, but are you proposing a= rename?=C2=A0 APR 2.0
is the right time for that...
= =C2=A0
whereas the dups use that
'n' in 'strndup' to signify that we have a size parameter

Indeed... follows the general stdc patte= rn.
=C2=A0
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 overt= hinking, and stumbling to come up with the
= most concise and accurate name.=C2=A0 Renaming suggestions and
deprecation of the old names are welcome.=C2=A0 These a= re good
discussions to have, we made many i= mprovements 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 b= ecause it
is a str[n]casecmp implementation= - however, that doesn't tell the=C2=A0
user that it is "unusual" but equivalent function that breaks fr= om
posix in that it deliberately chooses no= t to use the locale and is
primarily for wi= re protocols.=C2=A0 Thus the _token_ suggestion, but
I am open to other uniqifiers.=C2=A0 I'm not keen on coming u= p with
a new mishmash of str case len cmp e= quality blah that will be
harder for review= ers to decipher when reviewing commits.
I know you are in a hurry to just do some= thing, but usually the stuff=C2=A0
we just = hurry through many of us regret later, as piles of httpd.h cruft=C2=A0
can attest.=C2=A0 How many headers do you know = that contain explicit
sighs?=C2=A0 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 A= PI 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 to= ward the entire APR=C2=A0
approach - which = has never offered the shoot-from-the-hip approach=C2=A0
that earlier httpd releases enjoyed.=C2=A0 But these decisions= were put=C2=A0
down in reaction to frequen= t breakage for developers prior to httpd 2,=C2=A0
and are in place precisely because APR wants other developers=C2=A0<= /div>
beyond the world of httpd to have trust and= confidence in the API=C2=A0
they are codin= g to.=C2=A0 Hopefully httpd module authors can enjoy the
same level of confidence.

--001a1140ccc00cf7220525644952--