Re: [PROPOSAL] cgi_exec_info_t: detached addrspace fieldscombined
To replace the addrspace field that was added in the cgi_exec_info_t struct in mod_cgi.h I will like to propose extending the use of the detached (apr_int32_t) field in cgi_exec_info_t and apr_procattr_t structs. Currently that field is set to 0 by default and 1 if the process to be created will be a detached one. What I will like to do to is to add an address space option to set the second bit of that field in order to flag the new process to load or not in a new address space. The detached field in cgi_exec_info_t is set to 0 for all platforms and is used only in mod_netware and mod_win32. The changes will need to be back ported in order for NetWare to work after log.c r r1.145 is back ported. Follow a partial patch, I will certainly like to have suggestions: Thank you, I'm not even going to look at this for 1.0 :-( Plan is to roll rc2 on Sunday for a hopeful release on Wed next week. :-) david
Re: apr-iconv 1.0
At 06:30 PM 6/23/2004, David Reid wrote: I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 - they are seperate subsets with their own set of issues. APR 1.0 does not require apr-util or apr-iconv, there is no dependency. So no holdup of David's plans. Well, I'd agree on apr-iconv (haven't even rolled a 1.0 rc yet) but apr-util needs to be released the same time as apr. Our 2 biggest users (httpd svn) both use both (if that makes sense) so if we have apr 1.0, we have apr-util 1.0. Well, we can't ignore apr-iconv, apr-util has a dependency upon it for those platforms without a native port of iconv. H But nothing precludes us from rolling up apr and dropping it upon the world, then rolling up apr-util and dropping that 1.0.0 in a separate step. Sorry but that's a REALLY horrible precedent to set. Yeah APR is 1.0 but apr-util isn't... I agree there is no need to tie the versioning, but I think for the initial release of a major number they should be, so apr 2.0 and apr-util 2.0 should also be tied and released on the same date, whereas apr-util 1.1 can go out anytime. If people want to veto the candidate and force a retag with new code then that's one thing. when I roll 1.0 it'll be all 3 repo's at the same time, as will RC2. snip Why does this hold up an apr-util 1.0 ? Please elaborate further. Because apr-util 1.0 consumes apr-iconv, at least for non-unix distros. It does slightly annoy me that there has been a decent sized interval to discsuss such issues and only now are they being brought up. Agreed - wish there were more eyes on the code. My attention was solely focused on apr for the past weeks. I think we very nearly have that right, so now i'm looking sideways at apr-util and how it could defy developer's expectations. And the build breakage pointed out to me how wonky the current apr-iconv API really was (and mostly, my fault in the first place :) Sorry you haven't had enough time (I know you've been busy), but there aren't any votes for/against this and we (I) imposed a deadline to avoid exactly this sort of drawn out delay. If the answer to the question does what we have now work is yes then apr-util 1.0 is good to go. Sorry, but eventually you have to make a decision. I haven't seen anyone state that what we have doesn't work, so I see no reason to hold things up for yet another code tweak at the 11th hour. david
Re: cvs commit: apr/network_io/unix sockaddr.c
On Fri, Jun 25, 2004 at 01:51:46PM -, [EMAIL PROTECTED] wrote:
--- sockaddr.c 1 Jun 2004 19:50:14 - 1.52
+++ sockaddr.c 25 Jun 2004 13:51:46 - 1.53
@@ -767,6 +767,19 @@
if (shift 0) {
return APR_EBADIP;
}
+/*@@@ WARNING: BEWARE:
insert rant about putting bugs in bug databases
+The man page for inet_pton()/inet_aton() et.al. says:
+ All numbers supplied as ``parts'' in a `.' notation may be decimal,
+ octal, or hexadecimal, as specified in the C language (i.e., a
leading 0x
+ or 0X implies hexadecimal; otherwise, a leading 0 implies octal;
other-
+ wise, the number is interpreted as decimal).
+OTOH, man atoi says:
+ The atoi() function [...] is equivalent to:
+ (int)strtol(nptr, (char **)NULL, 10);
+which forces interpretation as _decimal_. As a result, this routine will
+interpret a string 0177...0001 as 177.0.0.1, while inet_pton()
+will interpret it as 127.0.0.1!
+@@@*/
inet_pton() is not required to do that, or even is required not to.
What issue did you encounter?
http://www.opengroup.org/onlinepubs/009695399/functions/inet_ntop.html
The inet_pton() function does not accept other formats (such as the
octal numbers, hexadecimal numbers, and fewer than four numbers that
inet_addr() accepts).
joe
Re: Unix-only code (was Re: svn commit: r10060 - trunk/subversion/libsvn_fs)
On Fri, Jun 25, 2004 at 10:59:55AM -0400, Greg Hudson wrote: On Thu, 2004-06-24 at 17:47, Joe Orton wrote: Support for the sticky/setgid/setuid bits has been in APR for a short while, on both branches. Thanks for pointing this out. But you guys appear to have introduced a bad bug in the process: APR_OS_DEFAULT now includes APR_USETID, APR_GSETID, and APR_WSTICKY. The first two bits are ignored on file and directory creation, but the third is not. Ah good catch Greg. Interestingly apr_file_open() interprets APR_OS_DEFAULT as meaning use 0666 on Unix whereas apr_dir_make() really just maps the bits across. I'll change the new constants to be 0x[248]000 to avoid this issue as you suggest. Thanks a lot. Note that changing the definition of APR_OS_DEFAULT will not solve this problem, since programs compiled against apr 0.9.4 will have used the old APR_OS_DEFAULT value. You need to use flag values outside of 0x0FFF for the new bits. (All of the above refers to the 0.9 branch, but may also be true of the 1.0 branch. Let me know if further action is required to make sure this gets fixed.)
Re: apr-iconv 1.0
David Reid wrote: If the answer to the question does what we have now work is yes then apr-util 1.0 is good to go. +1 The apr-iconv API is unfortunate, and the fact that it doesn't support transliteration like GNU libiconv is worse, but most uses of apr-iconv will be through the apr-util xlate wrapper, so it's not so important to clean up the API. Also, if we're going to change the API, we might as well move base it on the iconv-2.0 version (we're currently using the 1.0 as a baseline). -- Brane
Re: apr-iconv 1.0
At 12:35 PM 6/25/2004, Branko Čibej wrote: David Reid wrote: If the answer to the question does what we have now work is yes then apr-util 1.0 is good to go. +1 The apr-iconv API is unfortunate, and the fact that it doesn't support transliteration like GNU libiconv is worse, but most uses of apr-iconv will be through the apr-util xlate wrapper, so it's not so important to clean up the API. Also, if we're going to change the API, we might as well move base it on the iconv-2.0 version (we're currently using the 1.0 as a baseline). Is there a non-[l]gpl iconv 2? I found one is freebsd ports, that I think is the current (and has a new maintainer.) Want to be certain we are speaking about the same one. I'm tempted to say we explicitly declare libapriconv as a private library of libaprutil, just as the bundled expat is, with no public api support. That simplifies things to simply @doxygenate the apr-iconv header to say this is an internal api for use by apr-util, and pointing them to those functions. The goal would be to allow us to redo the latest bsd-licensed iconv to support other platforms, with or without apr, as an opaque dependency. Bill
Re: apr-iconv 1.0
Can I get a vote on apr-iconv in this respect? At 01:12 PM 6/25/2004, William A. Rowe, Jr. wrote: I'm tempted to say we explicitly declare libapriconv as a private library of libaprutil, just as the bundled expat is, with no public api support. That simplifies things to simply @doxygenate the apr-iconv header to say this is an internal api for use by apr-util, and pointing them to those functions. The goal would be to allow us to redo the latest bsd-licensed iconv to support other platforms, with or without apr, as an opaque dependency. E.g. plugging in any iconv, even a non-iconv translation backend behind our apr-util's xlate API, would ensure nobody would 'count on' anything but apr-util apr_xlate_xxx to exist.
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote: At 12:35 PM 6/25/2004, Branko ibej wrote: David Reid wrote: If the answer to the question does what we have now work is yes then apr-util 1.0 is good to go. +1 The apr-iconv API is unfortunate, and the fact that it doesn't support transliteration like GNU libiconv is worse, but most uses of apr-iconv will be through the apr-util xlate wrapper, so it's not so important to clean up the API. Also, if we're going to change the API, we might as well move base it on the iconv-2.0 version (we're currently using the 1.0 as a baseline). Is there a non-[l]gpl iconv 2? The one we're using is version 1.0 from Konstantin Chugev, and IIRC it's a BSD thing. In the meantime, he's released 2.0. I found one is freebsd ports, that I think is the current (and has a new maintainer.) Want to be certain we are speaking about the same one. I think we are, yes. I'm tempted to say we explicitly declare libapriconv as a private library of libaprutil, just as the bundled expat is, with no public api support. That simplifies things to simply @doxygenate the apr-iconv header to say this is an internal api for use by apr-util, and pointing them to those functions. The goal would be to allow us to redo the latest bsd-licensed iconv to support other platforms, with or without apr, as an opaque dependency. +1. I don't see why we'd need a separate apr-iconv public API, since we already have apr_xlate. -- Brane
