Re: El-Kabong -- HTML Parser
On Mon, Sep 09, 2002 at 11:21:04PM -0700, Greg Stein wrote: On Mon, Sep 09, 2002 at 01:33:25PM -0700, Jon Travis wrote: Ok, since I'm not seeing any activity towards getting this integrated, I'd like to set a deadline. This would help me out, since it gives direction as to where the project can go, as well as the ASF since political discussion shouldn't weigh down the process. It will just save us all a lot of time energy. Anyway, I'd like to give an additional week to the ASF to deal with the code. Next Monday, if it hasn't been decided I'll look into other options. Jon -- The HTTP Server Project, the APR Project, and the ASF will not abide by your threats of taking the code elsewhere. We will not be subject to coercive behavior, nor do we look kindly upon the attempt. The ASF is about working together. Your message certainly does not mesh with our concepts of community and respect. The ASF is apparently not about working together, since I (and everyone else who is not on the PMC list) have been entirely left out of all this conversation which is going on behind closed doors. I am not trying to coerce anyone -- I'm merely trying to put a limit on the maximum amount of time that this will be debated. That is a perfectly valid, and responsible thing to do. Frankly, there is no need or driving force for us to accept code donations. That means it isn't possible to hold this over our heads. We can easily choose to ignore the whole thing, with no real loss to our fundamental ideals and to our communities. It seems as though that is exactly what you've done -- ignored it. I am constantly probing for information as to where this stands, both via these lists and asking on the #apr IRC channel. You're interpretation if holding this over your head is fairly outrageous, since Apache exists perfectly fine without this contribution. As of this moment, I'm going to recommend that the ASF will work directly with Covalent management regarding the donation. The other members involved may certainly choose to continue working through you [to Covalent], as I do not speak for them, but I seriously doubt that will be the case. Your behavior does not bode well for your continued involvement in the process. That's quite the attack (and one which fits in well with your concepts of community and respect?) . All decisions which have been made about this project (Open sourcing it, setting a deadline, etc.) have been dictated by management at Covalent. If you want to persuade your management to publish the code through a different owner, or under a different license, then please feel free. If Covalent management chooses to not donate the code to the ASF, then so be it -- that is their choice. But take your coercive tactics elsewhere. Regards, Greg Stein Chairman, Apache Software Foundation These are not coercive tactics. These are processes which are beneficial to both the ASF and Covalent. I cannot continually monitor the progress of this project for eternity. I'm astonished that this deadline email has caused such a response. This sets an extremely bad precedent for other companies (or anyone for that matter) who wants to contribute to the ASF. Personally (Covalent hat off), it's a bummer that this is your response to the donation. I was the one who originally proposed it to management, they agreed to it, and now I've gotten involved in all kinds of politics and inflamatory emails. That's a long way from being excited about contritributing to the ASF, and sadly seems like more trouble than it's worth. -- Jon
Re: El-Kabong -- HTML Parser
Any word on this? (take 2) -- Jon On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon
Re: El-Kabong -- HTML Parser
My comments inline: On Tue, Sep 03, 2002 at 02:53:03PM -0400, [EMAIL PROTECTED] wrote: There are currently two possible avenues. 1) The code goes into apr-util. 2) The code goes into a sandbox project. The APR option is faster, but there is some misgivings about whether it belongs in apr-util. The vote was done, and it seems to be accepted, but Greg was keeping tally, so I don't have the exact numbers about where it would go. I _think_, and I could be wrong, that it would be put in apr-util/html as a separate piece of apr-util. The second option will take a bit longer, because the sandbox project will need to be created first. I have tried to answer without letting any of my personal opinions show in the message, because that has caused some problems before. The real question now, is given those two options, which would you prefer. Not saying that your preference is the only factor i the decision, but it should be taken into account. Either one is fine to me. Integrating the code into apr-util is probably an easier setup, but will require more work to adapt to the build system and change the symbols (and of course I'm quite liking the name 'el-kabong' ;-)). There are also some people questioning why we are moving so quickly on this. The general feeling is that we should find the best fit before taking the code. If you are in a rush, then that would change things, but the understanding was just that you wanted to be kept in the loop about what is happening. Keep pinging, but the conversation is on-going, and very active, so there is little chance that it won't happen. It is really just a matter of time now. Ryan I'm not in a rush, I just like to know where things stand. Since this discussion is seemingly happening off-list, I can't differentiate between no discussion or a heated one. I'd prefer this to be on-list, as I think it does affect the users of APR, and it would allow me to monitor the progress here. -- Jon
Re: El-Kabong -- HTML Parser
On Thu, Aug 29, 2002 at 06:42:39PM +0200, Dirk-Willem van Gulik wrote: On Thu, 29 Aug 2002, Jon Travis wrote: Any word on this? These things take time... and it pays off to do them well. There is absolutely no rush. Just wanted a word. More often than not, when something stops being discussed on the list, it drops off the face of the earth. I should know, I have many patches who've taken such a fall.. ;-) -- Jon
Re: El-Kabong -- HTML Parser
On Thu, Aug 29, 2002 at 11:29:24AM -0700, Aaron Bannert wrote: On Thu, Aug 29, 2002 at 02:24:28PM -0400, Ryan Bloom wrote: +1 from me, I prefer APR actually. I am really uncomfortable with this going under the APR project. As things stand right now, it just doesn't fit with what we have stated our goals to be. If you want to change our stated goals, then go ahead and do it. Just committing code that doesn't fit with our goals isn't the way to do that. (I will defer answering this for an apr-only discussion.) I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. I'm +1 on integrating it into our XML stuff. I consider it to be equivalent to apr-util, so either we put it inside apr-util, or we create a new APR subproject or sub-library for it. I'm not keen on integrating it into the APR XML layer for a few reasons: 1 - APR's XML is not SAX-stylee. El-Kabong is. That isn't to say that E-K couldn't get a full object model interface, but it doesn't have it now. 2 - XML and HTML, while related, have several large differences which won't make a nice API (IMO). 3 - El-Kabong is quite speedy, and throwing another layer of indirection on top of it isn't particularly appealing. -- Jon
Re: El-Kabong -- HTML Parser
On Thu, Aug 29, 2002 at 02:30:35PM -0700, Sander van Zoest wrote: On Thu, 29 Aug 2002, Jon Travis wrote: On Thu, Aug 29, 2002 at 11:29:24AM -0700, Aaron Bannert wrote: On Thu, Aug 29, 2002 at 02:24:28PM -0400, Ryan Bloom wrote: I will make one exception to that statement. If it lands inside of APR-util, under the XML directory, and it is made to work with the XML parser, I can accept that landing spot. As it fits in closer with our goals (I think). Jim, I can't decide if this is what you meant or not. I'm +1 on integrating it into our XML stuff. I consider it to be equivalent to apr-util, so either we put it inside apr-util, or we create a new APR subproject or sub-library for it. I'm not keen on integrating it into the APR XML layer for a few reasons: 1 - APR's XML is not SAX-stylee. El-Kabong is. That isn't to say that E-K couldn't get a full object model interface, but it doesn't have it now. Expat is a stream based parsers that is pretty similar to SAX2. It isn't a DOM xml parser. What does this have to do with anything? Expat is uninvolved here. I was talking about the APR XML API, which may-or-may-not wrap Expat. That API is DOM style. -- Jon
El-Kabong -- HTML Parser
Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. -- Jon
Re: El-Kabong -- HTML Parser
On Mon, Aug 26, 2002 at 08:49:38PM -0700, Justin Erenkrantz wrote: On Mon, Aug 26, 2002 at 08:32:16PM -0700, Jon Travis wrote: Hi all... Jon Travis here... Covalent has written a pretty keen HTML parser (called el-kabong) which we'd like to offer to the ASF for inclusion in APR-util (or whichever other umbrella it fits under.) It's faster than anything I can find, provides a SAX stylee interface, uses APR for most of its operations (hash tables, etc.), and has a pretty nice testsuite. We use it in our code to re-write HTML on the fly. I would be the initial maintainer of the code. Please voice any interest, thanks. Interested, but would like to see the code first. =) -- justin Yeah, thought about that, however the problem is that if the ASF doesn't accept it, then it is unlikely that it will be under an ASF style license. So it's kinda a chicken egg problemo.. :-( -- Jon
Re: El-Kabong -- HTML Parser
I personally think it belongs as some kind of sub-project to httpd, but not in the same tree. -- Jon On Tue, Aug 27, 2002 at 12:43:17PM -0400, Jim Jagielski wrote: Aaron Bannert wrote: On Tue, Aug 27, 2002 at 11:02:47AM -0400, Ryan Bloom wrote: I would prefer that this became it's own project either under the httpd project or the APR project. I don't believe that it should be a part of the APR-util library however. The functionality provided by el-kabong seems like a good fit within APR. I think it would be fine if el-kabong became a new subproject of APR. Personally, I think it's very cool that E-K is being folded into the ASF. I think the httpd project is a better fit however, simply because APR should be protocol ignorant. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: El-Kabong -- HTML Parser
Perhaps it doesn't belong anywhere in the ASF and should just be Open Sourced through other means. The problem is that the subproject is HTTP Server, and there are lots of nice things that don't really fit with that project, but in a more general 'web' project, which would include clients/servers/libs. -- Jon On Tue, Aug 27, 2002 at 09:58:25AM -0700, Aaron Bannert wrote: I don't understand. Is there something in httpd that would need el-kabong? Flood could definately use it, but I really don't want to make flood dependent on both httpd and APR, especially when flood is a _client_ and the httpd _server_ project is a server. HTML is more general than server-side HTTP, IMHO. -aaron On Tue, Aug 27, 2002 at 09:54:48AM -0700, Jon Travis wrote: I personally think it belongs as some kind of sub-project to httpd, but not in the same tree. -- Jon On Tue, Aug 27, 2002 at 12:43:17PM -0400, Jim Jagielski wrote: Aaron Bannert wrote: On Tue, Aug 27, 2002 at 11:02:47AM -0400, Ryan Bloom wrote: I would prefer that this became it's own project either under the httpd project or the APR project. I don't believe that it should be a part of the APR-util library however. The functionality provided by el-kabong seems like a good fit within APR. I think it would be fine if el-kabong became a new subproject of APR. Personally, I think it's very cool that E-K is being folded into the ASF. I think the httpd project is a better fit however, simply because APR should be protocol ignorant. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: El-Kabong -- HTML Parser
Well, if people are agreeing to this, can we get someone involved in the HTTPD project (non-Covalent affiliated) to review and approve/decline? Volunteers? -- Jon On Tue, Aug 27, 2002 at 01:22:03PM -0400, Jim Jagielski wrote: I didn't mean in the same tree at all! :) But, as you said, a subproj under HTTPD Jon Travis wrote: I personally think it belongs as some kind of sub-project to httpd, but not in the same tree. -- Jon On Tue, Aug 27, 2002 at 12:43:17PM -0400, Jim Jagielski wrote: Aaron Bannert wrote: On Tue, Aug 27, 2002 at 11:02:47AM -0400, Ryan Bloom wrote: I would prefer that this became it's own project either under the httpd project or the APR project. I don't believe that it should be a part of the APR-util library however. The functionality provided by el-kabong seems like a good fit within APR. I think it would be fine if el-kabong became a new subproject of APR. Personally, I think it's very cool that E-K is being folded into the ASF. I think the httpd project is a better fit however, simply because APR should be protocol ignorant. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: El-Kabong -- HTML Parser
On Tue, Aug 27, 2002 at 07:38:50PM +0200, Dirk-Willem van Gulik wrote: On Tue, 27 Aug 2002, Jim Jagielski wrote: Aaron Bannert wrote: On Tue, Aug 27, 2002 at 11:02:47AM -0400, Ryan Bloom wrote: I would prefer that this became it's own project either under the httpd project or the APR project. I don't believe that it should be a part of the APR-util library however. The functionality provided by el-kabong seems like a good fit within APR. I think it would be fine if el-kabong became a new subproject of APR. Personally, I think it's very cool that E-K is being folded into the ASF. I think the httpd project is a better fit however, simply because APR should be protocol ignorant. What community of developers within the ASF, within the httpd project, needs this functionality today ? It seems to me that you could have used it in your mod_acronym, and avoided quite a few of the 'caveats' that you have listed in the code. Or what viable external community is likely to be behind it at some point - or is very likely (say just as likely as expat :-) or regex to need it in the very near future ? Dw -- Jon
APR time test failing
My time test is failing. I get a mismatch: checking localtime explode == GMT implode mismatch apr_now()1021948993979908 apr_implode() returned 1021981393979908 error delta was 324 should have been 0 -- Jon
Re: APR time test failing
On Mon, May 20, 2002 at 07:47:24PM -0700, Jon Travis wrote: My time test is failing. I get a mismatch: checking localtime explode == GMT implode mismatch apr_now()1021948993979908 apr_implode() returned 1021981393979908 error delta was 324 should have been 0 Sorry, should have been more thorough. This problem only occurs under Windows for me. Under UNIX the test works fine. BTW: I had to add shell32.lib to the link line for the apr tests to build. Has anyone been running the testsuite on windows? ;-) -- Jon
Re: APR time test failing
x86 -- Windows 2000 -- 5.00.2195 (that's shark to you, Will.. ;-) ) -- Jon On Mon, May 20, 2002 at 09:55:02PM -0500, William A. Rowe, Jr. wrote: Hardware? OS? Rev level? At 09:47 PM 5/20/2002, you wrote: My time test is failing. I get a mismatch: checking localtime explode == GMT implode mismatch apr_now()1021948993979908 apr_implode() returned 1021981393979908 error delta was 324 should have been 0 -- Jon
Re: APR time test failing
On Mon, May 20, 2002 at 11:17:49PM -0500, William A. Rowe, Jr. wrote: At 09:51 PM 5/20/2002, Jon Travis wrote: On Mon, May 20, 2002 at 07:47:24PM -0700, Jon Travis wrote: My time test is failing. I get a mismatch: checking localtime explode == GMT implode mismatch apr_now()1021948993979908 apr_implode() returned 1021981393979908 error delta was 324 should have been 0 Sorry, should have been more thorough. This problem only occurs under Windows for me. Under UNIX the test works fine. 9 hour delta... evidently we missed timezone data, and then MIS compensated for the DST delta [otherwise, where would 9hrs - PST come from... PDT should be 7hrs from GMT, no?] Yeah, it's an interesting one -- apr_time_now() should be GMT though, and not have anything to do with timezones (not saying they aren't playing a part in this issue, though). This problem manifested itself when a program I was running on Windows had a hard time communicating with a program under UNIX. Both used apr_time_now() to determine the current time, and I guess they came up with different answers. -- Jon
Re: APR time test failing
On Tue, May 21, 2002 at 01:01:48AM -0400, Cliff Woolley wrote:
On Tue, 21 May 2002, Cliff Woolley wrote:
Index: time.c
===
RCS file: /home/cvs/apr/time/win32/time.c,v
retrieving revision 1.32
diff -u -d -r1.32 time.c
--- time.c 15 Apr 2002 00:01:09 - 1.32
+++ time.c 21 May 2002 04:41:09 -
@@ -215,7 +215,6 @@
if (days 0) {
return APR_EBADDATE;
}
-days -= xt-tm_gmtoff;
*t = days * APR_USEC_PER_SEC + xt-tm_usec;
return APR_SUCCESS;
}
Yeah, that was it. The unix and win32 apr_time_exp_get() functions are
virtually identical except for that line on win32. Does this patch allow
the tests to pass? I dug up the original email on the subject (thank you
MARC ;). Credit for this should go to INOUE Seiichiro
[EMAIL PROTECTED], who originally reported this in message
[EMAIL PROTECTED] on [EMAIL PROTECTED]
Didn't seem to fix it, though maybe my Windows compile-fu is weak. I'll
leave it up to Will.
-- Jon
Solaris binary compatability bug
I'm having a small problem with binary compatability between Solaris 2.6 and a particular Solaris 8 box that I have. If I build a simple program on a 2.6 box and call: apr_sockaddr_info_get(..., 255.255.255.255, ...) It works fine on the 2.6 box, but fails on the 8.x box. There is a check in the configure stage which defines GETHOSTBYNAME_HANDLES_NAS -- this succeeds on 2.6, and fails on 8.x (obviously not binary compatable.) There is a way in which we can fix this: Why don't we _always_ run the segment of code in sa_common.c (~ line 420) where we do a strspn to see if we are dealing with dotted-quad notation? -- Jon
Re: Solaris binary compatability bug
Here's the patch which rips out the configure macros and the ifdefs
in sa_common.c.
-- Jon
Index: configure.in
===
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.425
diff -u -u -r1.425 configure.in
--- configure.in4 Apr 2002 21:35:43 - 1.425
+++ configure.in24 Apr 2002 18:56:00 -
@@ -1519,8 +1519,6 @@
APR_CHECK_SOCKADDR_SA_LEN
-APR_CHECK_GETHOSTBYNAME_NAS
-
dnl Check the types only if we have gethostbyname_r
if test $ac_cv_func_gethostbyname_r = yes; then
APR_CHECK_GETHOSTBYNAME_R_STYLE
Index: build/apr_network.m4
===
RCS file: /home/cvspublic/apr/build/apr_network.m4,v
retrieving revision 1.15
diff -u -u -r1.15 apr_network.m4
--- build/apr_network.m424 Mar 2002 16:01:33 - 1.15
+++ build/apr_network.m424 Apr 2002 18:56:00 -
@@ -170,53 +170,6 @@
fi
])
-
-dnl
-dnl check for gethostbyname() which handles numeric address strings
-dnl
-AC_DEFUN(APR_CHECK_GETHOSTBYNAME_NAS,[
- AC_CACHE_CHECK(for gethostbyname() which handles numeric address strings,
ac_cv_gethostbyname_nas,[
- AC_TRY_RUN( [
-#ifdef HAVE_SYS_TYPES_H
-#include sys/types.h
-#endif
-#ifdef HAVE_NETINET_IN_H
-#include netinet/in.h
-#endif
-#ifdef HAVE_ARPA_INET_H
-#include arpa/inet.h
-#endif
-#ifdef HAVE_NETDB_H
-#include netdb.h
-#endif
-#ifdef HAVE_STDLIB_H
-#include stdlib.h
-#endif
-void main(void) {
-struct hostent *he = gethostbyname(127.0.0.1);
-if (he == NULL) {
-exit(1);
-}
-he = gethostbyname(255.255.255.255);
-if (he == NULL) {
-exit(1);
-}
-else {
-exit(0);
-}
-}
-],[
- ac_cv_gethostbyname_nas=yes
-],[
- ac_cv_gethostbyname_nas=no
-],[
- ac_cv_gethostbyname_nas=yes
-])])
-if test $ac_cv_gethostbyname_nas = yes; then
- AC_DEFINE(GETHOSTBYNAME_HANDLES_NAS, 1, [Define if gethostbyname() handles
nnn.nnn.nnn.nnn])
-fi
-])
-
dnl
dnl Checks the definition of gethostbyname_r and gethostbyaddr_r
dnl which are different for glibc, solaris and assorted other operating
Index: network_io/unix/sa_common.c
===
RCS file: /home/cvspublic/apr/network_io/unix/sa_common.c,v
retrieving revision 1.54
diff -u -u -r1.54 sa_common.c
--- network_io/unix/sa_common.c 1 Apr 2002 14:13:45 - 1.54
+++ network_io/unix/sa_common.c 24 Apr 2002 18:56:01 -
@@ -417,7 +417,6 @@
family = APR_INET; /* we don't support IPv6 here */
}
-#ifndef GETHOSTBYNAME_HANDLES_NAS
if (*hostname = '0' *hostname = '9'
strspn(hostname, 0123456789.) == strlen(hostname)) {
struct in_addr ipaddr;
@@ -426,7 +425,6 @@
save_addrinfo(p, *sa, ipaddr, port);
}
else {
-#endif
#if APR_HAS_THREADS !defined(GETHOSTBYNAME_IS_THREAD_SAFE) \
defined(HAVE_GETHOSTBYNAME_R) !defined(BEOS)
#if defined(GETHOSTBYNAME_R_HOSTENT_DATA)
@@ -474,9 +472,7 @@
port);
++curaddr;
}
-#ifndef GETHOSTBYNAME_HANDLES_NAS
}
-#endif
}
else {
(*sa)-pool = p;
Re: Unix missing fd 0..2, Win32 service missing stdin/out/err handles
On Sat, Apr 13, 2002 at 01:20:25PM -0500, William A. Rowe, Jr. wrote: A suggestion to implement in apr_app_initialize, but first some background. Without harming apr_initialize(), which should continue to be useful for initializing apr in a non-apr application (e.g. a mod_jk connector built with apr, that is written for Apache 1.3), I had started an apr_app_initialize a while back. One paragraph of background; I created apr_app_initialize primarily to allow us to use the apr signals API... if we detect the app is running in a console, we can set up the Windows console API in the signal schema. If we detect we are running 'as a service', we can set up the Windows SCM context immediately, and when apr_daemonize is invoked, we can report 'started'. We also use apr_app_initialize on Win32 to transform our Unicode input (command line args and the environment table) into utf-8 internal encoding. So far, so simple [yet I haven't had three days to put the signals together.] Back to the purpose of this post; Because third party libraries have a nasty habit of dropping messages out to stderr or stdout... and will sometimes even poll stdin (think passphrases or other bits in encryption libraries, etc) ... it is rather dangerous for -our- applications to ever use fd 0..2. Sure, you can chalk it up to a bug in the caller, but imagine if 'by chance' we open up an sdbm as fd 2. Another library prints something to stderr and bang ... database is corrupted. On the Win32 side, same goes for FILE *'s stdin, stderr and stdout, for the low level 'fd's 0..2 (not really fd's as unix knows them, but the clib's table of Win32 handles), and the Win32 standard handles. Win32 services have -no- STD handles, even when they are command line apps. So, on the unix side, within apr_app_initialize, I suggest calling fopen(/dev/null, ) until it returns an fd 2. On the Win32 side, I suggest calling GetStandardHandle() and filling in any missing stdhandles with the appropriate FILE*'s fd's handle after opening 'NUL' in the clib, so all three bases are covered. If we end up with an fd 2, then we immediately close that last /dev/null file and go on. Does this make good sense? Not particularly. The operating system pre-allocates those fd's (0..2 for Unix) -- why would opening an SDBM ever return any of those file descriptors? The only way would be if the consumer closed those handles beforehand. If the user does something like that, their program is broken -- we shouldn't try to work around that. -- Jon
Re: Unix missing fd 0..2, Win32 service missing stdin/out/err handles
On Sun, Apr 14, 2002 at 10:18:57AM +0200, Sascha Schumann wrote: The operating system pre-allocates those fd's (0..2 for Unix) -- why would opening an SDBM ever return any of those file descriptors? The only way would be if the consumer closed those handles beforehand. If the user does something like that, their program is broken -- we shouldn't try to work around that. There are various daemons which close all fds after forking and detaching from the tty, because they have no need to keep those fds open. open(), socket() or accept() can then return an fd in the range 0..2. If APR would be used in such a context, the scenario Bill laid out would be quite possible. As I described, it would be possible for a user to close those descriptors before doing something like say, opening an SDBM. If they then try to _write_ to those (via something like write() to stderr), then that is a programming error which we should not be trying to solve. -- Jon
Re: Unix missing fd 0..2, Win32 service missing stdin/out/err handles
On Sun, Apr 14, 2002 at 01:38:25PM +0200, Sascha Schumann wrote: As I described, it would be possible for a user to close those descriptors before doing something like say, opening an SDBM. If they then try to _write_ to those (via something like write() to stderr), then that is a programming error which we should not be trying to solve. Not necessarily. The daemon might use a third-party library which writes diagnostic messages to stderr (something like Oracle's libs). Or even worse, the user might be running the application on FreeBSD where malloc(3) writes messages to stderr, if configured to do so. There are probably more cases where this can happen which the app's author cannot influence. Supplying module authors with a function which addresses this issue makes sense from that perspective. If a user knows that a third-party library (Oracle, whatever) can provide messages to stderr, and they knowingly close that file descriptor without dup()ing it elsewhere, then that is a bug in their software. Having APR open a bunch of file-descriptors so that this fixes a potential problem (IMO bug in their software) is just wasting file descriptors. -- Jon
Unprotected symbols
I get symbol collisions between apr_thread_proc.h and ap_alloc.h (in Apache 1.3) with things like 'kill_never', etc. It would be nice to make sure all these symbols are namespace protected (there are a ton of them in APR.) -- Jon
Re: Time funniness between HPUX and everyone else
Someone want to commit this?
-- Jon
Index: time.c
===
RCS file: /var/covalent/.CVS/apache-cvs/apr-cvs/time/unix/time.c,v
retrieving revision 1.58
diff -u -r1.58 time.c
--- time.c 2002/01/02 20:12:34 1.58
+++ time.c 2002/01/09 20:50:14
@@ -92,6 +92,9 @@
if (daylightOnOff) {
return server_gmt_offset + daylightOffset;
}
+#else
+if(tm-tm_isdst)
+return server_gmt_offset + 3600;
#endif
return server_gmt_offset;
#endif
@@ -341,7 +344,6 @@
struct timeval now;
time_t t1, t2;
struct tm t;
-int was_dst;
gettimeofday(now, NULL);
t1 = now.tv_sec;
@@ -352,10 +354,9 @@
#else
t = *gmtime(t1);
#endif
-was_dst = (t.tm_isdst 0);
t.tm_isdst = -1;
t2 = mktime(t);
-server_gmt_offset = (apr_int32_t) difftime(t1, t2) + (was_dst ? 3600 : 0);
+server_gmt_offset = (apr_int32_t) difftime(t1, t2);
#endif
}
On Mon, Jan 07, 2002 at 05:53:18PM -0800, Jon Travis wrote:
Nope, you're right on that one -- just slap the return in the ifdef
for netware and commit, I guess.. ;-)
-- Jon
On Mon, Jan 07, 2002 at 05:48:06PM -0800, Brian Pane wrote:
Jon Travis wrote:
Ok, here's a small patch which gets things working correctly for me.
Not sure if this patch is correct, though.
Thanks, I just tested this on Solaris and Linux, and it produced
the expected results on both. The patch logic looks okay, with one
possible exception: if NETWARE is defined, do you really want to fall
into the if (tm-tm_isdst) check if the if (daylightOnOff) check
fails? Or should it be:
#ifdef NETWARE
/* Need to adjust the global variable each time otherwise
the web server would have to be restarted when daylight
savings changes.
*/
if (daylightOnOff) {
return server_gmt_offset + daylightOffset;
}
#else
if(tm-tm_isdst) {
return server_gmt_offset + 3600;
}
#endif
return server_gmt_offset;
#endif
Re: Time funniness between HPUX and everyone else
Ok, here's a small patch which gets things working correctly for me. Not sure if this patch is correct, though. -- Jon Index: time.c === RCS file: /home/cvspublic/apr/time/unix/time.c,v retrieving revision 1.58 diff -u -r1.58 time.c --- time.c 2 Jan 2002 20:12:34 - 1.58 +++ time.c 7 Jan 2002 21:13:09 - @@ -93,6 +94,8 @@ return server_gmt_offset + daylightOffset; } #endif +if(tm-tm_isdst) +return server_gmt_offset + 3600; return server_gmt_offset; #endif } @@ -341,7 +344,6 @@ struct timeval now; time_t t1, t2; struct tm t; -int was_dst; gettimeofday(now, NULL); t1 = now.tv_sec; @@ -352,10 +354,9 @@ #else t = *gmtime(t1); #endif -was_dst = (t.tm_isdst 0); t.tm_isdst = -1; t2 = mktime(t); -server_gmt_offset = (apr_int32_t) difftime(t1, t2) + (was_dst ? 3600 : 0); +server_gmt_offset = (apr_int32_t) difftime(t1, t2); #endif } On Fri, Jan 04, 2002 at 02:59:42PM -0800, Brian Pane wrote: Jon Travis wrote: On Fri, Jan 04, 2002 at 02:39:56PM -0800, Brian Pane wrote: Jon Travis wrote: BTW, note the huge comment in unix/time.c:apr_unix_time_setup() which says that this (* broken) implementation is what was wanted. Yes, in the sense that it produces the same results that we had back when we were doing the GMT offset within get_offset(). I just ran your test case on Solaris 2.8, and it produces the same results as HP-UX--both with the latest unix/time.c and with the last version (rev 1.51) from before the GMT offset computation was moved into apr_unix_time_setup(). So, you're just saying that it is just as broken as it was before the change in 1.52? Right. Basically, that field has different semantics on HP-UX and Solaris than it has on Linux. That doesn't seem to be a problem for any of the time manipulation code, although the fact that the field is part of the publicly visible apr_time API is bad for portability. I'm in favor of making the semantics consistent across all platforms (e.g., using the Netware approach as you described) if it can be done without breaking anything else. --Brian
Time funniness between HPUX and everyone else
I've been experiencing some time funniness on HPUX with respect to the calculation of the GMT offset. Here are the results under HPUX: apr_explode_localtime(xt, 0); xt.tm_gmtoff = -28800 xt.tm_isdst = 0 apr_explode_localtime(xt, 96768122600); xt.tm_gmtoff = -28800 xt.tm_isdst = 1 Under my Linux box: apr_explode_localtime(xt, 0); xt.tm_gmtoff = -28800 xt.tm_isdst = 0 apr_explode_localtime(xt, 96768122600); xt.tm_gmtoff = -25200 xt.tm_isdst = 1 I believe the problem lies with the fact that we attempt to calculate 'server_gmt_offset' in the apr_unix_setup_time() function, but the gmt offset my change when requesting times in a dst different than the current one. For instance, the current time is used to formulate server_gmt_offset, and we are not in DST here in US/Pacific. Under Linux, we get the gmtoffset for free with our localtime call. I thought it might be that my HPUX box was just wacked out of its gourd wrt the timezone setup, but it looks correct after investigation. Perhaps the correct thing to do is determine the gmt offset during dst and also when we are not in it, and use different ones in get_offset() after checking dst (similar to the netware code.) -- Jon
Re: Time funniness between HPUX and everyone else
BTW, note the huge comment in unix/time.c:apr_unix_time_setup() which says that this (* broken) implementation is what was wanted. -- Jon * AFAIK the P in APR stands for 'portability.' Getting one value under Linux, and another one under HPUX doesn't seem like a Good Thing. On Fri, Jan 04, 2002 at 12:24:11PM -0800, Jon Travis wrote: I've been experiencing some time funniness on HPUX with respect to the calculation of the GMT offset. Here are the results under HPUX: apr_explode_localtime(xt, 0); xt.tm_gmtoff = -28800 xt.tm_isdst = 0 apr_explode_localtime(xt, 96768122600); xt.tm_gmtoff = -28800 xt.tm_isdst = 1 Under my Linux box: apr_explode_localtime(xt, 0); xt.tm_gmtoff = -28800 xt.tm_isdst = 0 apr_explode_localtime(xt, 96768122600); xt.tm_gmtoff = -25200 xt.tm_isdst = 1 I believe the problem lies with the fact that we attempt to calculate 'server_gmt_offset' in the apr_unix_setup_time() function, but the gmt offset my change when requesting times in a dst different than the current one. For instance, the current time is used to formulate server_gmt_offset, and we are not in DST here in US/Pacific. Under Linux, we get the gmtoffset for free with our localtime call. I thought it might be that my HPUX box was just wacked out of its gourd wrt the timezone setup, but it looks correct after investigation. Perhaps the correct thing to do is determine the gmt offset during dst and also when we are not in it, and use different ones in get_offset() after checking dst (similar to the netware code.) -- Jon
apr-util gdbm/db crappiness
When trying to link a simple program using apr-util using libtool, I get numerous errors about gdbm (and db) functions not being found. It turns out that libaprutil.la's dependency_libs variable doesn't contain a bunch of needed stuff (such as -lgdbm -ldb, etc.) apr-util obviously knows about this, as it substitutes them correctly into APRUTIL_EXPORT_LIBS in export_vars.sh. Is there a reason we aren't doing a -lstuff when creating the libtool archive? This used to work. -- Jon
Re: apr-util gdbm/db crappiness
On Fri, Jan 04, 2002 at 01:43:28PM -0800, Justin Erenkrantz wrote: On Fri, Jan 04, 2002 at 01:12:20PM -0800, Jon Travis wrote: When trying to link a simple program using apr-util using libtool, I get numerous errors about gdbm (and db) functions not being found. It turns out that libaprutil.la's dependency_libs variable doesn't contain a bunch of needed stuff (such as -lgdbm -ldb, etc.) apr-util obviously knows about this, as it substitutes them correctly into APRUTIL_EXPORT_LIBS in export_vars.sh. Is there a reason we aren't doing a -lstuff when creating the libtool archive? This used to work. AIX doesn't support inter-library dependencies with libtool. We tried this and had to back it out. I'm waiting for Jeff to give us a go-ahead (since he vetoed it last time). IIRC, before the vacations started, he was playing with libtool on AIX. So, we may make progress on this soonish. -- justin Hrmm -- it'd be nice to have. Break all platforms just to fix AIX? ;-) -- Jon
Re: Time funniness between HPUX and everyone else
On Fri, Jan 04, 2002 at 02:39:56PM -0800, Brian Pane wrote: Jon Travis wrote: BTW, note the huge comment in unix/time.c:apr_unix_time_setup() which says that this (* broken) implementation is what was wanted. Yes, in the sense that it produces the same results that we had back when we were doing the GMT offset within get_offset(). I just ran your test case on Solaris 2.8, and it produces the same results as HP-UX--both with the latest unix/time.c and with the last version (rev 1.51) from before the GMT offset computation was moved into apr_unix_time_setup(). So, you're just saying that it is just as broken as it was before the change in 1.52? -- Jon
Re: apr_vformatter changes optimizations
On Mon, Oct 01, 2001 at 08:51:54PM -0700, Greg Stein wrote: On Mon, Oct 01, 2001 at 08:28:17PM -0700, Jon Travis wrote: On Mon, Oct 01, 2001 at 04:07:13PM -0700, Greg Stein wrote: On Mon, Oct 01, 2001 at 01:43:55PM -0700, Jon Travis wrote: I was thinking today that it would be nice to be able to pre-parse *rintf style format strings into an intermediate array. This would have the potential to speed up code which uses *rintf by quite a bit. Potential vs. demonstrated? Can you show that we're spendig significant time parsing the format strings? Going and throwing a bunch of complexity for a small speedup might not be worthwhile :-) Personally, I'm guessing that more time is spent assembling than parsing. Since the parsing code is intermingled with the code that throws it into the final buffer, there isn't a good way of profiling this right now. In order to figure out if we are, or not, I'll have to actually write the code to just-parse or just-output the data, which is the end result of my question, anyway. Well, if you want to do the code, who's to stop you? :-) But I would think it ought to be perf-tested before it goes in. Agreed. Working on it now. Another useful feature of being able to pre-parse the list would be to have the ability to examine the datatypes required for the format. Why is this terribly useful, you ask? Well, v*printf takes a va_list, which cannot portably be constructed at run-time. However, if we had a special apr_va_list, which we could take as an argument to our special formatter (which also took a preparsed array), we could generate and use v*printf formats/arguments at runtime. Assume that you create a sentinel-terminated list of non-opaque structures. An app could then programmatically declare that stuff ahead of time and skip the whole parse step. Look at it as a sequence of instructions for assembling bits into a string. Sure, you could skip the whole parse phase and generate the list yourself. That is my end-goal here. Nobody would ever want to get rid of the parsing code, though. Either way, it would be nice to be able to (at run time) construct va_list style arguments to pass off to a v*printf function. That is a bit of a poor point in C. :-( -- Jon
[PATCH] apr_uri_unparse_components monthly reminder
This is a reminder, sent out once a month, about a previous APR
patch submission. It includes the patch, description, and how to
use it to fix broken code.
Original patch post date: Jul-18-2001
Description:
apr_uri_unparse_components can unparse components into an invalid
URI. If the components contain either a user or password, the
unparsed URI will always contain an '@' symbol. This is incorrect,
since the UNP_OMITPASSWORD and UNP_OMITUSER flags can affect
this functionality. I.e. if the components contain either a user
or password, and flags to omit both the user and password from the
unparsed URI are given, the output should contain no '@' symbol.
The patch:
? uri/patch.diff
Index: uri/apr_uri.c
===
RCS file: /home/cvspublic/apr-util/uri/apr_uri.c,v
retrieving revision 1.6
diff -u -u -r1.6 apr_uri.c
--- uri/apr_uri.c 2001/06/13 22:56:23 1.6
+++ uri/apr_uri.c 2001/07/23 17:21:39
@@ -139,7 +139,9 @@
(uptr-password !(flags UNP_OMITPASSWORD))
? ((flags UNP_REVEALPASSWORD) ? uptr-password :
)
: ,
- @, NULL);
+ ((uptr-user !(flags UNP_OMITUSER)) ||
+(uptr-password !(flags UNP_OMITPASSWORD))) ? @
+: , NULL);
/* Construct scheme://site string */
if (uptr-hostname) {
Re: [PATCH] apr_uri_unparse_components monthly reminder
Uhm. My patch is totally seperate from this bug report, aside from the
fact that they both occur within the unparse_uri_components function.
-- Jon
On Fri, Aug 17, 2001 at 01:21:31PM -0500, William A. Rowe, Jr. wrote:
Jon,
can you take a look at the attached bug report, and assure that your patch
handles this case correctly before we apply it today? I'd like to lick all
the bugs, and wanted to be sure that this report is dead as well (on 2.0.)
Bill
- Original Message -
From: Jon Travis [EMAIL PROTECTED]
To: dev@apr.apache.org
Sent: Friday, August 17, 2001 12:55 PM
Subject: [PATCH] apr_uri_unparse_components monthly reminder
This is a reminder, sent out once a month, about a previous APR
patch submission. It includes the patch, description, and how to
use it to fix broken code.
Original patch post date: Jul-18-2001
Description:
apr_uri_unparse_components can unparse components into an invalid
URI. If the components contain either a user or password, the
unparsed URI will always contain an '@' symbol. This is incorrect,
since the UNP_OMITPASSWORD and UNP_OMITUSER flags can affect
this functionality. I.e. if the components contain either a user
or password, and flags to omit both the user and password from the
unparsed URI are given, the output should contain no '@' symbol.
The patch:
? uri/patch.diff
Index: uri/apr_uri.c
===
RCS file: /home/cvspublic/apr-util/uri/apr_uri.c,v
retrieving revision 1.6
diff -u -u -r1.6 apr_uri.c
--- uri/apr_uri.c 2001/06/13 22:56:23 1.6
+++ uri/apr_uri.c 2001/07/23 17:21:39
@@ -139,7 +139,9 @@
(uptr-password !(flags UNP_OMITPASSWORD))
? ((flags UNP_REVEALPASSWORD) ? uptr-password : )
: ,
- @, NULL);
+ ((uptr-user !(flags UNP_OMITUSER)) ||
+ (uptr-password !(flags UNP_OMITPASSWORD))) ? @
+ : , NULL);
/* Construct scheme://site string */
if (uptr-hostname) {
Return-Path: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Date: 17 Aug 2001 06:24:27 -
From: Dongqiang Bai [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: apache-api/8195: ap_unparse_uri_components() steals -query info
when -path is NULL
Number: 8195
Category: apache-api
Synopsis: ap_unparse_uri_components() steals -query info when -path
is NULL
Confidential: no
Severity: non-critical
Priority: medium
Responsible:apache
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: apache
Arrival-Date: Thu Aug 16 23:30:01 PDT 2001
Closed-Date:
Last-Modified:
Originator: [EMAIL PROTECTED]
Release:1.3.20
Organization:
apache
Environment:
OS: Linux(acturally all OS)
PATCH: without any patch
Compiler: gcc(actually un-related)
Description:
I'm writing apache modules using ap_* functions.
Looking at such html tag:
FORM action=?act=1
Use ap_parse_uri_componets() to parse the URI ?act=1, then use
ap_unparse_uri_components() to recover the URI, you will get the different
results, and the convert=revert result is an empty string .
This was not a problem in apache_1.3.14.
How-To-Repeat:
Look at the source code of apache_1.3.20/src/main/util_uri.c:line 250 is
better.
Or insert following test code into apache to be called and do debug:
--
void test_ap_unparse_uri_components(pool *anypool)
{
uri_components *uptr = ap_pcalloc(anypool, sizeof(uri_components));
int status = ap_parse_uri_components(anypool, ?act=1, uptr);
char *new_uri = ap_unparse_uri_components(anypool, uptr, 0);
// verify the new_uri became empty here
if (strlen(new_uri) == 0)
// this shows the problem
exit(1);
}
Fix:
Add one line before 250 line of util_uri.c:
line 250: +)if (uptr-path)
line 251: ) parts[j++] = uptr-path;
Release-Note:
Audit-Trail:
Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include [EMAIL PROTECTED] in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as general/1098: or ]
[Re: general/1098:). If the subject doesn't match this ]
[pattern, your message will be misfiled and ignored. The ]
[apbugs address is not added to the Cc line of messages from ]
[the database automatically because of the potential for mail ]
[loops. If you do not include this Cc, your reply may be ig- ]
[nored unless you are responding to an explicit request from a ]
[developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]
Re: Observations on fragmentation in SMS pools
On Mon, Jul 09, 2001 at 04:50:31PM -0700, [EMAIL PROTECTED] wrote: cool, huh? [and it's only 1024 LOC yes i know it's not portable like APR i was v.impressed that someone actually looked at it when i first mentioned it here, btw ] so *grin*. can you guarantee thread-safety on apr_hash_t using apr_hash_first()/next()/this()? can you guarantee complete traversal with multiple simultaneous adders, deleters, readers and writers? and does anyone want a challenge of porting tdb to apr? *grin* Challenge, did somebody say challenge? I'm always up for a challenge. :-) BTW: Why are tables in APR at all? The only thing I see used is headers in apr-util hooks code, and in the xml, but that of course can be fixed. Step 1, remove tables from APR, Step 2, remove tables from Apache. agh! tables are kinda... entrenched into xvl. okay, maybe not: only 10 instances of apr_table_make. 10 of apr_table_do [which is why i was advocating it: i really like it :)] Tables are in APR, because were originally moved from Apache to APR before APR-util existed. They should really move to apr-util. They should never be removed from Apache. Tables are useful because they garuantee a general order to the data, namely, the order you insert information into the table. Hashes have a different use case. Tables should definitely be moved to APR-util if they are to remain. As for Apache, there are better structures that dictate general order than the table. IMNSHO, the only reason tables are still in Apache is inertia. Nobody wants to go through and change everything to a more sane data structure. Case insensitive searches -- linear search time over the table ... ugh. -- Jon
Re: Observations on fragmentation in SMS pools
On Tue, Jul 10, 2001 at 04:52:25PM +0200, Luke Kenneth Casson Leighton wrote: ... errr.. should i be using apr_hash_t or something? :) Yes. okay. will take a look at it, to see where i could use it. i have a suspicion that a lot of instances i really _need_ the case-insensitive stuff, and also need the dual set and add capability. not least because HTTP POST args can have this: key1=value1key1=value2 and, correct me if i'm wrong, here, that results in a table: (key1, value1) (key1, value2) I'll reply to this one, but it also goes towards the other guys pointing to the spec. There isn't anything wrong with storing both the sensitive and then keying off of a toupper of the string, and chaining it off the end if the entry already exists in the table (for multiple headers of the same name). One could even take the existing table code, add a field for the toupper'd string, add a small adler32 (or whatever cksum is to your liking) field, and get a lot better performance than we see now. Of course I still am no big fan of the API. -- Jon
Re: Observations on fragmentation in SMS pools
On Mon, Jul 09, 2001 at 05:49:24PM +0200, Luke Kenneth Casson Leighton wrote: On Sun, Jul 08, 2001 at 11:06:33AM -0700, Justin Erenkrantz wrote: On Sun, Jul 08, 2001 at 11:04:09AM -0700, Jon Travis wrote: As for the ability to use shared memory for this ... yeah that is an interesting idea. What are your actual use cases for that? Ian posted a patch to do something like this - I think he wanted a hash table that was shared across all processes. The problem gets to be growing the memory space, but I think his use case was with fixed memory. He could probably tell more about how he wanted to do it. Both rbb and I suggested that this is what SMS was designed for. Have a SMS that is backed by shared memory and then the hashtable immediately becomes shared when you create it with this shared memory SMS. No change needed to the hashtable code. okay, had an idea here that i thought i'd share with you about shmem/pools/sms. lessons from tdb's design. accessing shmem, you really have to treat it as a very-fast-file-in-memory. therefore, best thing to do to be able to easily access sections of it: treat the shmem as an in-memory database. the simplest way to fit that into the existing APR code is to have direct support for apr_table_t in a pool-based or sms-based shared-memory-segment. if you examine tdb.c's design, you will notice that apr_table_do() becomes identical to [but more powerful than] tdb_traverse(). apr_array_header_t? again, i haven't thought about it, but you could likely get away with the same thing. The apr_table_t is just an apr_array_header_t with a specific key/val entry type. in other words, i think that supporting apr_pool_t on top of shared memory (via sms) is going to be tricky: in my opinion, the apr_pool_xxx() API _and_ the apr_sms_xxx() API can't Deal With shared memory at a convenient user-acceptable level. HOWEVER! supporting the data types that apr_pool_xxx() USES is a different matter. by supporting apr_array_header_t (if possible) and apr_table_t the complexity of messing about will be hidden from users of these data types, but they will work quite happily as expected, even if it's shared memory behind them. what people think? I think you are in for a ride on this one. The API for dealing with the tables is currently rather poor, since typically it is casted to an array and then iterated over. The strcasecmp's of the table code are a whole seperate issue. I would think that the (nearly analagous) apr_hash_t would better suit what you are talking about here. BTW: Why are tables in APR at all? The only thing I see used is headers in apr-util hooks code, and in the xml, but that of course can be fixed. Step 1, remove tables from APR, Step 2, remove tables from Apache. -- Jon
Re: [PATCH] socket family fetching
On Mon, Apr 30, 2001 at 05:58:30PM -0400, Jeff Trawick wrote:
Jon Travis [EMAIL PROTECTED] writes:
I need a routine to fetch the socket family. I could just refer
to the information in the sockaddr_t address length, but that is
rather hackish. Anyway, here tis. We should also probably be
moving towards making the sockaddr_t an opaque type, or at least
some of the members.
I think that the better place to look is addr-sa.sin.sin_family.
Hopefully you should be able to return this as-is.
On first thought, the partial opaqueness makes sense (though I don't
know how to do that neatly in C). Thinking down the road, the number
of accessor functions could get out of hand (similar to the
apr_fileinfo_t issue). I'm mostly happy with apps peering into the
apr_sockaddr_t, though maybe we need to make it friendlier by adding
(e.g.) a family field which starts out as APR_UNSPEC and is set once
we know the family.
Just do like so:
(in apr_network_io.h)
typedef struct apr_sockaddr_priv_t apr_sockaddr_priv_t;
struct apr_sockaddr_t {
apr_pool_t *pool;,
...
apr_sockaddr_priv_t *privdata;
};
Then define apr_sockaddr_priv_t in either a header local only to the
subdirectories (network_io, etc.) or simply define the members in the
actual C file that uses it.
Poking about in the sockaddr_in is kinda fun and easy to do, but is really
going to let people shoot themselves fairly easily, I fear.
-- Jon
[PATCH] socket family fetching
I need a routine to fetch the socket family. I could just refer
to the information in the sockaddr_t address length, but that is
rather hackish. Anyway, here tis. We should also probably be
moving towards making the sockaddr_t an opaque type, or at least
some of the members.
Index: include/apr_network_io.h
===
RCS file: /home/cvspublic/apr/include/apr_network_io.h,v
retrieving revision 1.101
diff -u -u -r1.101 apr_network_io.h
--- include/apr_network_io.h2001/04/03 01:09:51 1.101
+++ include/apr_network_io.h2001/04/30 16:31:30
@@ -596,6 +596,16 @@
apr_sockaddr_t *sockaddr);
/**
+ * Return the family in an APR socket address.
+ * @param family The family from the socket address.
+ * @param sockaddr The socket address to reference.
+ * @deffunc apr_status_t apr_sockaddr_family_get(apr_int32_t *family,
apr_sockaddr_t *sockaddr)
+ */
+APR_DECLARE(apr_status_t) apr_sockaddr_family_get(apr_int32_t *family,
+ apr_sockaddr_t *sockaddr);
+
+
+/**
* Set the IP address in an APR socket address.
* @param sockaddr The socket address to use
* @param addr The IP address to attach to the socket.
Index: network_io/unix/sa_common.c
===
RCS file: /home/cvspublic/apr/network_io/unix/sa_common.c,v
retrieving revision 1.32
diff -u -u -r1.32 sa_common.c
--- network_io/unix/sa_common.c 2001/03/15 21:54:59 1.32
+++ network_io/unix/sa_common.c 2001/04/30 16:32:07
@@ -114,6 +114,21 @@
return APR_SUCCESS;
}
+APR_DECLARE(apr_status_t) apr_sockaddr_family_get(apr_int32_t *family,
+ apr_sockaddr_t *sockaddr)
+{
+if(sockaddr-salen == sizeof(struct sockaddr_in))
+*family = APR_INET;
+#if APR_HAVE_IPV6
+else if(sockaddr-salen == sizeof(struct sockaddr_in6))
+*family = APR_INET6;
+#endif
+else
+*family = APR_UNSPEC;
+
+return APR_SUCCESS;
+}
+
APR_DECLARE(apr_status_t) apr_sockaddr_ip_get(char **addr,
apr_sockaddr_t *sockaddr)
{
[PATCH: apr_hash.c]
apr_hash.c has a very obscure bug in it, though I'm very surprised nobody
has been bitten by it before. It is possible, when expanding the table,
to use an old pointer and overwrite the hash entry value upon return from
find_entry. Anyway, this small patch fixes it. I have a testhash.c for
the tests directory as well, if anyone thinks we need it.
-- Jon
Index: apr_hash.c
===
RCS file: /home/cvspublic/apr/tables/apr_hash.c,v
retrieving revision 1.16
diff -u -u -r1.16 apr_hash.c
--- apr_hash.c 2001/03/07 17:57:19 1.16
+++ apr_hash.c 2001/03/09 00:32:27
@@ -275,10 +275,7 @@
he-klen = klen;
he-val = val;
*hep = he;
-/* check that the collision rate isn't too high */
-if (++ht-count ht-max) {
- expand_array(ht);
-}
+ht-count++;
return hep;
}
@@ -310,6 +307,10 @@
else {
/* replace entry */
(*hep)-val = val;
+/* check that the collision rate isn't too high */
+if (ht-count ht-max) {
+expand_array(ht);
+}
}
}
/* else key not present and val==NULL */
