You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Eric Covener <co...@gmail.com> on 2009/03/09 00:57:34 UTC
Fwd: svn commit: r751555 - in /apr/apr-util/branches/1.2.x: CHANGES
include/apr_ldap.h.in include/apr_ldap.hw
It occured to me just after changing this macro that its addition
broke versioning rules when it was added to 1.2.x post-release.
The new macro has already been in a release, 1.2.12. Is it better to
leave it or pull it?
---------- Forwarded message ----------
From: <co...@apache.org>
Date: Sun, Mar 8, 2009 at 7:45 PM
Subject: svn commit: r751555 - in /apr/apr-util/branches/1.2.x:
CHANGES include/apr_ldap.h.in include/apr_ldap.hw
To: commits@apr.apache.org
Author: covener
Date: Sun Mar 8 23:45:24 2009
New Revision: 751555
URL: http://svn.apache.org/viewvc?rev=751555&view=rev
Log:
backport r751456 from trunk:
It's not safe to ask an SDK that doesn't define LDAP_DEFAULT_LIMIT to
use -1, because it might put it on the wire as an unsigned int.
We previously special-cased this for the MSSDK, but it needs to be more general.
PR23356
Modified:
apr/apr-util/branches/1.2.x/CHANGES
apr/apr-util/branches/1.2.x/include/apr_ldap.h.in
apr/apr-util/branches/1.2.x/include/apr_ldap.hw
Modified: apr/apr-util/branches/1.2.x/CHANGES
URL: http://svn.apache.org/viewvc/apr/apr-util/branches/1.2.x/CHANGES?rev=751555&r1=751554&r2=751555&view=diff
==============================================================================
--- apr/apr-util/branches/1.2.x/CHANGES [utf-8] (original)
+++ apr/apr-util/branches/1.2.x/CHANGES [utf-8] Sun Mar 8 23:45:24 2009
@@ -2,6 +2,11 @@
Changes with APR-util 1.2.13
+ *) APR_LDAP_SIZELIMIT should prefer LDAP_DEFAULT_LIMIT/-1 when the
+ SDK supports it, but in the absence of LDAP_DEFAULT_LIMIT (and
+ LDAP_NO_LIMIT/0) it is not safe to use a literal -1.
+ PR23356 [Eric Covener]
+
*) Better error detection for bucket allocation failures.
[Jim Jagielski]
Modified: apr/apr-util/branches/1.2.x/include/apr_ldap.h.in
URL: http://svn.apache.org/viewvc/apr/apr-util/branches/1.2.x/include/apr_ldap.h.in?rev=751555&r1=751554&r2=751555&view=diff
==============================================================================
--- apr/apr-util/branches/1.2.x/include/apr_ldap.h.in (original)
+++ apr/apr-util/branches/1.2.x/include/apr_ldap.h.in Sun Mar 8 23:45:24 2009
@@ -97,15 +97,19 @@
/*
* For ldap function calls that input a size limit on the number of
returned elements
* Some SDKs do not have the define for LDAP_DEFAULT_LIMIT (-1) or
LDAP_NO_LIMIT (0)
+ * LDAP_DEFAULT_LIMIT is preferred as it allows inheritance from
whatever the SDK
+ * or process is configured for.
*/
-#if APR_HAS_ZOS_LDAPSDK
-#define APR_LDAP_SIZELIMIT LDAP_NO_LIMIT
-#else
#ifdef LDAP_DEFAULT_LIMIT
#define APR_LDAP_SIZELIMIT LDAP_DEFAULT_LIMIT
#else
-#define APR_LDAP_SIZELIMIT -1 /* equivalent to LDAP_DEFAULT_LIMIT */
+#ifdef LDAP_NO_LIMIT
+#define APR_LDAP_SIZELIMIT LDAP_NO_LIMIT
+#endif
#endif
+
+#ifndef APR_LDAP_SIZELIMIT
+#define APR_LDAP_SIZELIMIT 0 /* equivalent to LDAP_NO_LIMIT, and what
goes on the wire */
#endif
/*
Modified: apr/apr-util/branches/1.2.x/include/apr_ldap.hw
URL: http://svn.apache.org/viewvc/apr/apr-util/branches/1.2.x/include/apr_ldap.hw?rev=751555&r1=751554&r2=751555&view=diff
==============================================================================
--- apr/apr-util/branches/1.2.x/include/apr_ldap.hw (original)
+++ apr/apr-util/branches/1.2.x/include/apr_ldap.hw Sun Mar 8 23:45:24 2009
@@ -90,9 +90,20 @@
/*
* For ldap function calls that input a size limit on the number of
returned elements
* Some SDKs do not have the define for LDAP_DEFAULT_LIMIT (-1) or
LDAP_NO_LIMIT (0)
+ * LDAP_DEFAULT_LIMIT is preferred as it allows inheritance from
whatever the SDK
+ * or process is configured for.
*/
+#ifdef LDAP_DEFAULT_LIMIT
+#define APR_LDAP_SIZELIMIT LDAP_DEFAULT_LIMIT
+#else
+#ifdef LDAP_NO_LIMIT
#define APR_LDAP_SIZELIMIT LDAP_NO_LIMIT
+#endif
+#endif
+#ifndef APR_LDAP_SIZELIMIT
+#define APR_LDAP_SIZELIMIT 0 /* equivalent to LDAP_NO_LIMIT, and what
goes on the wire */
+#endif
/* Note: Macros defining const casting has been removed in APR v1.0,
* pending real support for LDAP v2.0 toolkits.
--
Eric Covener
covener@gmail.com
Re: Fwd: svn commit: r751555 - in /apr/apr-util/branches/1.2.x:
CHANGES include/apr_ldap.h.in include/apr_ldap.hw
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> On Sun, Mar 8, 2009 at 5:18 PM, Bojan Smojver <bo...@rexursive.com> wrote:
>> On Sun, 2009-03-08 at 19:57 -0400, Eric Covener wrote:
>>> It occured to me just after changing this macro that its addition
>>> broke versioning rules when it was added to 1.2.x post-release.
>>>
>>> The new macro has already been in a release, 1.2.12. Is it better to
>>> leave it or pull it?
>> The damage has already been done. No point causing it twice by pulling
>> it. IMHO etc.
>
> I agree, but we need to be more vigilant about this in the future :(
Agreed, but you MUST @bug it in the doxygen that it is not a 1.2 API.
Re: Fwd: svn commit: r751555 - in /apr/apr-util/branches/1.2.x:
CHANGES include/apr_ldap.h.in include/apr_ldap.hw
Posted by Paul Querna <pa...@querna.org>.
On Sun, Mar 8, 2009 at 5:18 PM, Bojan Smojver <bo...@rexursive.com> wrote:
> On Sun, 2009-03-08 at 19:57 -0400, Eric Covener wrote:
>> It occured to me just after changing this macro that its addition
>> broke versioning rules when it was added to 1.2.x post-release.
>>
>> The new macro has already been in a release, 1.2.12. Is it better to
>> leave it or pull it?
>
> The damage has already been done. No point causing it twice by pulling
> it. IMHO etc.
I agree, but we need to be more vigilant about this in the future :(
Re: Fwd: svn commit: r751555 - in /apr/apr-util/branches/1.2.x:
CHANGES include/apr_ldap.h.in include/apr_ldap.hw
Posted by Bojan Smojver <bo...@rexursive.com>.
On Sun, 2009-03-08 at 19:57 -0400, Eric Covener wrote:
> It occured to me just after changing this macro that its addition
> broke versioning rules when it was added to 1.2.x post-release.
>
> The new macro has already been in a release, 1.2.12. Is it better to
> leave it or pull it?
The damage has already been done. No point causing it twice by pulling
it. IMHO etc.
--
Bojan