APR/APU docs tag files
There is a number of projects that use APR/APU now and many of them could use Doxygen tag files to reference APR/APU APIs. So, here are two patches for doxygen.conf files in each repository. -- Bojan --- doxygen.conf-vanilla 2004-06-29 09:48:26.700425000 +1000 +++ doxygen.conf 2004-06-29 09:51:45.463209224 +1000 @@ -32,3 +32,5 @@ EXCLUDE_PATTERNS=*/acconfig.h \ */test/* \ */arch/* + +GENERATE_TAGFILE=docs/dox/apr.tag --- doxygen.conf-vanilla 2004-06-29 09:48:57.260779000 +1000 +++ doxygen.conf 2004-06-29 09:53:04.953124920 +1000 @@ -25,3 +25,5 @@ FULL_PATH_NAMES=YES # some autoconf guru needs to make configure set this correctly... STRIP_FROM_PATH=/root/apache/httpd-2.0-8/srclib/apr-util + +GENERATE_TAGFILE=docs/dox/apu.tag
Re: APR/APU docs tag files
There is a number of projects that use APR/APU now and many of them could use Doxygen tag files to reference APR/APU APIs. So, here are two patches for doxygen.conf files in each repository. These look harmless enough to me and if users would find them helpful I think we should include them. Anyone have any objections to this patch being applied for 1.0? (My doxygen experience isn't that vast). david
Re: cvs commit: apr/strings apr_strings.c
[EMAIL PROTECTED] wrote:
wrowe 2004/06/28 11:09:16
Modified:strings Tag: APR_0_9_BRANCH apr_strings.c
Log:
Avoid any edge case or clib bug that might result in a string
overflow of the fixed 5-byte buffer for our size function.
Returns the '' string when the buffer would overflow.
Backport of rev 1.47
Reviewed by: trawick
reviewed but not approved ;)
it still has the same bug (apr_snprintf() doesn't return 0 either)
Index: apr_strings.c
===
RCS file: /home/cvs/apr/strings/apr_strings.c,v
retrieving revision 1.42.2.2
retrieving revision 1.42.2.3
diff -u -r1.42.2.2 -r1.42.2.3
--- apr_strings.c 4 Apr 2004 15:21:08 - 1.42.2.2
+++ apr_strings.c 28 Jun 2004 18:09:16 - 1.42.2.3
@@ -429,7 +429,8 @@
return strcpy(buf, - );
}
if (size 973) {
-sprintf(buf, %3d , (int) size);
+if (apr_snprintf(buf, 5, %3d , (int) size) 0)
does not occur... apr_snprintf would return the number of bytes stored in case
of an overflow
Re: cvs commit: apr/build jlibtool.c
On Tuesday, June 29, 2004, at 02:41 PM, [EMAIL PROTECTED] wrote: martin 2004/06/29 05:41:11 Added: buildjlibtool.c Log: Commit the missing jlibtool.c from Justin's http://www.apache.org/~jerenkrantz/jlibtool.c -- It was referenced by configure --enable-experimental-libtool already. Also, it helps in building on platforms not directly supported by libtool (for those, libtools behaves utterly stupidly). Obtained from: http://www.apache.org/~jerenkrantz/jlibtool.c Reviewed by: jfclere apache.org Hello? What makes you think you can do that? Aside from having the wrong license, you don't have the right to commit Justin's code unless he tells you to do so on the public mailing list. You should ask him to do the commit himself, since that makes it a donation by the author rather than a copy by someone else. -1 to that commit. +1 to Justin fixing the license and committing the code. Roy
Re: cvs commit: apr configure.in
On Tue, Jun 29, 2004 at 02:10:48PM -, [EMAIL PROTECTED] wrote: --- configure.in14 Jun 2004 21:16:40 - 1.589 +++ configure.in29 Jun 2004 14:10:48 - 1.590 @@ -522,6 +522,8 @@ AC_SEARCH_LIBS(gethostbyname, nsl) AC_SEARCH_LIBS(gethostname, nsl) AC_SEARCH_LIBS(socket, socket) +dnl Search for -lbind / -lresolv only after having added -lsocket and -lnsl +AC_SEARCH_LIBS(res_init, bind resolv) This is not right, res_init() is not used anywhere inside APR so configure will pick up -lresolv unnecessarily on many platforms. What are you trying to solve here? joe
TR for 1.0
Well, the last issue seems to have been resolved and by the flurry of patches I guess folks are looking at the code?! So, I'll aim to create 1.0 RC2 tarballs later on tonight/tomorrow and then if all is well we'll release a 1.0 :-) david
Re: cvs commit: apr/build jlibtool.c
--On Tuesday, June 29, 2004 3:31 PM +0200 Roy T. Fielding [EMAIL PROTECTED] wrote: Hello? What makes you think you can do that? Aside from having the wrong license, you don't have the right to commit Justin's code unless he tells you to do so on the public mailing list. You should ask him to do the commit himself, since that makes it a donation by the author rather than a copy by someone else. -1 to that commit. +1 to Justin fixing the license and committing the code. Wow. Yah. Why did this get committed? And why now? Was there a particular reason that you wanted this? I'm fairly sure that there wasn't a discussion about this on [EMAIL PROTECTED] So where did this review happen? *scratches head* I'm not totally against relicensing and committing it, but especially so close to APR 1.0, I'd at least like to know why now. I believe in the past the feeling was that jlibtool should not be in the tree - Jeff and several others have their own libtool replacements, so, at the last ApacheCon, we had discussed taking a real effort and support all of them. *shrug* -- justin
Re: cvs commit: apr/build jlibtool.c
--On Tuesday, June 29, 2004 3:31 PM +0200 Roy T. Fielding [EMAIL PROTECTED] wrote: Hello? What makes you think you can do that? Aside from having the wrong license, you don't have the right to commit Justin's code unless he tells you to do so on the public mailing list. You should ask him to do the commit himself, since that makes it a donation by the author rather than a copy by someone else. -1 to that commit. +1 to Justin fixing the license and committing the code. Wow. Yah. Why did this get committed? And why now? Was there a particular reason that you wanted this? I'm fairly sure that there wasn't a discussion about this on [EMAIL PROTECTED] So where did this review happen? *scratches head* Sums up my own reaction. I'm not totally against relicensing and committing it, but especially so close to APR 1.0, I'd at least like to know why now. I believe in the past the feeling was that jlibtool should not be in the tree - Jeff and several others have their own libtool replacements, so, at the last ApacheCon, we had discussed taking a real effort and support all of them. *shrug* -- justin Actually I wasn't going to tag this for 1.0 anyways for the exact reasons you state. david
Re: cvs commit: apr/build jlibtool.c
That license needs to be updated. On Tue, Jun 29, 2004 at 12:41:11PM -, [EMAIL PROTECTED] wrote: martin 2004/06/29 05:41:11 Added: buildjlibtool.c Log: Commit the missing jlibtool.c from Justin's http://www.apache.org/~jerenkrantz/jlibtool.c -- It was referenced by configure --enable-experimental-libtool already. Also, it helps in building on platforms not directly supported by libtool (for those, libtools behaves utterly stupidly). Obtained from: http://www.apache.org/~jerenkrantz/jlibtool.c Reviewed by:jfclere apache.org Revision ChangesPath 1.1 apr/build/jlibtool.c Index: jlibtool.c === /* * The Apache Software License, Version 1.1 * * Copyright (c) 2000-2002 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, *if any, must include the following acknowledgment: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgment may appear in the software itself, *if and wherever such third-party acknowledgments normally appear. * * 4. The names Apache and Apache Software Foundation must *not be used to endorse or promote products derived from this *software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache, *nor may Apache appear in their name, without prior written *permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. */ -- Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] cgi_exec_info_t: detached addrspace fields combined
At 04:17 AM 6/28/2004, Joe Orton wrote: OK, the apr_procattr_addrspace_set() interface is sufficient to solve this problem, right? And there's no issue with back-porting that to the APR 0.9 branch? The only issue is how to use that interface from mod_cgi/the Netware MPM without requiring an httpd major MMN bump? So why not just overload the 'detached' field in cgi_exec_info_t inside mod_cgi/Netware MPM? That's should cause too much damange. Agreed, if that's a private structure, no bumps needed. -1 on overloading apr_procattr_detach_set() to do this, that's bad API design, and uglifying the APR API just to satisfy an httpd binary compat requirement just seems very wrong. I agree. If you want to overload the bit flags, that's fine, because the actual apr_procattr_t should be opaque to the user, correct? But having two seperate fn's to set detached v.s. addrspace seems like a much better public API.
apr pkgconfig use (apr.pc vs. apr-1.pc)
Imagine a library downstream from apr (say, Subversion) is trying to
follow the APR versioning guidelines
(http://apr.apache.org/versioning.html) in order to provide a stable
platform for third-party applications and libraries.
To do this, the downstream library must define the major version of
its upstream dependencies. If Subversion links against any old
version of APR it can find on the system, then the following sequence
of builds and installs breaks rapidsvn:
APR 0.9
svn 1.0
rapidsvn
APR 1.0
svn 1.1
because, although the APR soname has changed, the svn soname has not,
but it's exporting a different ABI (in relation to apr_off_t).
If that problem seems far from home, the same problem is going to
happen with {APR 0.9} {httpd 2.0.49} {plugin} {APR 1.0} {httpd
2.0.50}.
The solution to this problem is for the downstream library to rigidly
define the major version of its upstream dependencies. That's why
GNOME packages install things like libgnome-2.0.pc. (Which is
overboard; 2 would have been fine, and if you check you'll find that
the 2.0 didn't change for libgnome 2.2 or 2.4 or 2.6. But that's a
detail.) It is only this discipline which has allowed GNOME to manage
the GNOME 1 to 2 transition as gracefully as it did. (It's true that
GNOME 1 didn't use versioned library names or pkgconfig, but by
changing all the library names and adopting pkgconfig, GNOME 2
effectively created a separate universe, which is exactly the correct
thing for a major version upgrade, and is exactly the point of using
different library and pkgconfig names for a major version upgrade.)
So, please change the recently added pkgconfig support to install
apr-1.pc, so that upstream packages will run pkg-config --libs apr-1
instead of just looking for any old version of APR. By itself, that
won't help with the APR 0.9 to APR 1.x transition, but it will help
with APR 1.x to APR 2.x.
Separately, I will request that APR remove apr-config from APR 1.0 and
later in order to correctly manage the APR 0.9 - APR 1.0 transition,
but I bet that won't fly.
