You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 1998/06/19 05:46:52 UTC
[PATCH] Fixing ap_escape_quotes
I'd like to get the attached patch (or a version of it) into 1.3.1.
The main thing it does is make libap httpd-neutral again, so other
things (like stuff in src/support) can use libap routines without
dragging in a lot of httpd-specific crud. I'd just commit this,
but it changes MMN because it alters the ap_escape_quotes()
semantics.
It speeds ap_escape_quotes() up by a factor of about two, at
the cost of some memory. In this case, 8K on the stack when
an AuthName directive is being processed.
Since 1.3.1 is supposed to go out to-morrow (19 June) according
to STATUS, I can see this not going in. Dean will probably
spot either some errors or some massive improvements. I leave
it up to the RM, Jim, whether this should go in.
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Index: ap/ap_strings.c
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/ap/ap_strings.c,v
retrieving revision 1.5
diff -u -r1.5 ap_strings.c
--- ap_strings.c 1998/04/11 12:00:17 1.5
+++ ap_strings.c 1998/06/19 03:35:00
@@ -58,51 +58,60 @@
#include "httpd.h"
/*
- * Given a string, replace any bare " with \" .
+ * Given a string, replace any bare " with \" . If the result is longer than
+ * the output buffer, return NULL, otherwise the pointer to the output
string.
+ * The size is that of the complete buffer, including the byte for the
+ * terminal '\0'.
*/
-API_EXPORT(char *) ap_escape_quotes (pool *p, const char *instring)
+API_EXPORT(char *) ap_escape_quotes (char *dst, const char *src, size_t
dsize)
{
int newlen = 0;
- const char *inchr = instring;
- char *outchr, *outstring;
+ const char *inchr = src;
+ char *outchr = dst;
/*
* Look through the input string, jogging the length of the output
* string up by an extra byte each time we find an unescaped ".
*/
- while (*inchr != '\0') {
- newlen++;
+ for (;;) {
+ /*
+ * See if it's an unescaped quote.
+ */
if (*inchr == '"') {
- newlen++;
+ if ((newlen + 2) > (dsize - 1)) {
+ return NULL;
+ }
+ *outchr++ = '\\';
+ *outchr++ = *inchr++;
+ newlen += 2;
}
/*
* If we find a slosh, and it's not the last byte in the string,
* it's escaping something - advance past both bytes.
*/
- if ((*inchr == '\\') && (inchr[1] != '\0')) {
- inchr++;
- }
- inchr++;
- }
- outstring = ap_palloc(p, newlen + 1);
- inchr = instring;
- outchr = outstring;
- /*
- * Now copy the input string to the output string, inserting a slosh
- * in front of every " that doesn't already have one.
- */
- while (*inchr != '\0') {
- if ((*inchr == '\\') && (inchr[1] != '\0')) {
+ else if ((*inchr == '\\') && (inchr[1] != '\0')) {
+ if ((newlen + 2) > (dsize - 1)) {
+ return NULL;
+ }
*outchr++ = *inchr++;
*outchr++ = *inchr++;
+ newlen += 2;
}
- if (*inchr == '"') {
- *outchr++ = '\\';
+ else if (*inchr == '\0') {
+ break;
}
- if (*inchr != '\0') {
+ else {
+ if ((newlen + 1) > (dsize - 1)) {
+ return NULL;
+ }
*outchr++ = *inchr++;
+ newlen++;
}
}
- *outchr = '\0';
- return outstring;
+ /*
+ * Put the final character (the terminal '\0') into the output string
+ * and return it.
+ */
+ *outchr = *inchr;
+ return dst;
}
Index: include/ap.h
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/include/ap.h,v
retrieving revision 1.16
diff -u -r1.16 ap.h
--- ap.h 1998/05/11 20:42:35 1.16
+++ ap.h 1998/06/19 03:35:00
@@ -67,7 +67,7 @@
API_EXPORT(char *) ap_cpystrn(char *, const char *, size_t);
int ap_slack(int, int);
-API_EXPORT(char *) ap_escape_quotes(pool *, const char *);
+API_EXPORT(char *) ap_escape_quotes(char *dst, const char *src, size_t
dsize);
API_EXPORT(int) ap_snprintf(char *, size_t, const char *, ...);
API_EXPORT(int) ap_vsnprintf(char *, size_t, const char *, va_list ap);
int ap_execle(const char *, const char *, ...);
Index: include/http_config.h
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/include/http_config.h,v
retrieving revision 1.87
diff -u -r1.87 http_config.h
--- http_config.h 1998/05/27 14:01:31 1.87
+++ http_config.h 1998/06/19 03:35:00
@@ -275,7 +275,7 @@
* handle it back-compatibly, or at least signal an error).
*/
-#define MODULE_MAGIC_NUMBER 19980527
+#define MODULE_MAGIC_NUMBER 19980618
#define STANDARD_MODULE_STUFF MODULE_MAGIC_NUMBER, -1, __FILE__, NULL, NULL
/* Generic accessors for other modules to get at their own module-specific
Index: include/httpd.h
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/include/httpd.h,v
retrieving revision 1.224
diff -u -r1.224 httpd.h
--- httpd.h 1998/06/13 15:22:49 1.224
+++ httpd.h 1998/06/19 03:35:02
@@ -901,8 +901,6 @@
API_EXPORT(int) ap_ind(const char *, char); /* Sigh... */
API_EXPORT(int) ap_rind(const char *, char);
-API_EXPORT(char *) ap_escape_quotes (pool *p, const char *instring);
-
/* Common structure for reading of config files / passwd files etc. */
typedef struct {
int (*getch) (void *param); /* a getc()-like function */
Index: main/http_core.c
===================================================================
RCS file: /export/home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.204
diff -u -r1.204 http_core.c
--- http_core.c 1998/06/16 03:37:28 1.204
+++ http_core.c 1998/06/19 03:35:07
@@ -1909,8 +1909,12 @@
static const char *set_authname(cmd_parms *cmd, void *mconfig, char *word1)
{
core_dir_config *aconfig = (core_dir_config *)mconfig;
+ char qescaped[MAX_STRING_LEN];
- aconfig->ap_auth_name = ap_escape_quotes(cmd->pool, word1);
+ if (ap_escape_quotes(qescaped, word1, sizeof(qescaped)) == NULL) {
+ return "AuthName value too long (more than MAX_STRING_LEN bytes)";
+ }
+ aconfig->ap_auth_name = ap_pstrdup(cmd->pool, qescaped);
return NULL;
}
Re: [PATCH] Fixing ap_escape_quotes
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> Um... I think it sucks to take a routine which can handle arbitrary
> length inputs and turn it into something that has an upper limit. -1.
>
> If the pool thing bothers you then move ap_escape_quotes to util.c.
All right. I wish we had an httpd-neutral version, but so be it.
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: [PATCH] Fixing ap_escape_quotes
Posted by Dean Gaudet <dg...@arctic.org>.
Um... I think it sucks to take a routine which can handle arbitrary length
inputs and turn it into something that has an upper limit. -1.
If the pool thing bothers you then move ap_escape_quotes to util.c.
Dean
On Thu, 18 Jun 1998, Rodent of Unusual Size wrote:
> /*
> - * Given a string, replace any bare " with \" .
> + * Given a string, replace any bare " with \" . If the result is longer than
> + * the output buffer, return NULL, otherwise the pointer to the output
> string.
> + * The size is that of the complete buffer, including the byte for the
> + * terminal '\0'.
> */
Re: Apache 2.0, NSPR, C++, ...
Posted by Wan-Teh Chang <wt...@netscape.com>.
Dean Gaudet wrote:
> > One really ignorant question though. Is the NSPR code the same code
> > Netscape uses in their Enterprise Server product? If so, I am a tad weary
> > because I have had loads of reliability problems that look like threading
> > problems to me with those servers.
>
> >From what I understand (the netscape guys are here on new-httpd still I
> think so they could answer better), NSPR in some form is used in their
> enterprise server. But I don't think it's the same library that they
> released -- the released one is "nsprpub", for public I presume.
"nsprpub" was first released on 31 March 1998. Yes, nsprpubis a subset of the
complete nspr, but there is only one auxiliary
library that we cannot release, and the reason is that the copyright
of that library does not permit us to redistribute its source code,
just like Sun's copyright notice does not permit us to distribute
its JVM source code with Mozilla. I want to reassure
everyone that we didn't hide any "good stuff".
(The core nspr library is in mozilla/nsprpub/pr. The auxiliary
libraries are in mozilla/nsprpub/lib.)
On each platform, nspr may have more than one implementation.
In particular, on the major Unix platforms, nspr typically has
an implementation using only user-level threads, and an
implementation using native threads/pthreads.
Mozilla uses the user-level threads only implementation. The
reason is not for portability but to work around certain bugs
or constraints of X libraries. (I don't really know the details.)
Netscape's server products use the native threads/pthreads
implementation, which is the implementation we recommend,
and is the default build target.
Any new work we have done on the source code after
its initial release on 31 March 1998 has to follow the rules
of the Netscape/Mozilla Public License.
Wan-Teh
Re: Apache 2.0, NSPR, C++, ...
Posted by Ben Laurie <be...@algroup.co.uk>.
Alexei Kosut wrote:
>
> On Mon, 22 Jun 1998, Dean Gaudet wrote:
>
> > > If you can also stomach the idea of using C++ as a "better way to keep
> > > lists of functions than C" then we're really cooking! (err, yeah, I'm
> > > talking virtual functions here).
> >
> > No you'll have to whack on me some more. It's best for you to introduce a
> > subtle bug that you know I'll track down (i.e. put it in vhosts and then
> > nobody else will touch it ;)... a subtle bug that when found I'll realize
> > "oh duh, virtual functions solve this problem!" ;)
>
> Well, IMHO, putting virtual functions in the Apache core itself (at least,
> right now) won't fix anything, and as you (Dean) made me painfully aware
> earlier this year, they aren't the fastest buggers in the world (can
> anyone say "Java"?). I mean, I don't see the need for polymorphism right
> now, not without a real OO redesign of the core code.
>
> On the other hand, the Apache modules are just crying out for it... the
> module_struct structure in particular strikes me as a place that tries to
> approximate polymorphic derived classes using a C language feature that
> isn't perfect for the task.
That's _exactly_ what I had in mind!
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: Apache 2.0, NSPR, C++, ...
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Mon, 22 Jun 1998, Dean Gaudet wrote:
> > If you can also stomach the idea of using C++ as a "better way to keep
> > lists of functions than C" then we're really cooking! (err, yeah, I'm
> > talking virtual functions here).
>
> No you'll have to whack on me some more. It's best for you to introduce a
> subtle bug that you know I'll track down (i.e. put it in vhosts and then
> nobody else will touch it ;)... a subtle bug that when found I'll realize
> "oh duh, virtual functions solve this problem!" ;)
Well, IMHO, putting virtual functions in the Apache core itself (at least,
right now) won't fix anything, and as you (Dean) made me painfully aware
earlier this year, they aren't the fastest buggers in the world (can
anyone say "Java"?). I mean, I don't see the need for polymorphism right
now, not without a real OO redesign of the core code.
On the other hand, the Apache modules are just crying out for it... the
module_struct structure in particular strikes me as a place that tries to
approximate polymorphic derived classes using a C language feature that
isn't perfect for the task.
Or whatever...
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: Apache 2.0, NSPR, C++, ...
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 22 Jun 1998, Ben Laurie wrote:
> OK, now we're talking! Note that in C++ it is possible to have two
> strchr()s - one const, one non-const, without having to mess with three
> zillion (oh, OK, I exaggerate - two in this case, but for strcmp() it
> would be four, and so on) different names for each function.
Right.
> If you can also stomach the idea of using C++ as a "better way to keep
> lists of functions than C" then we're really cooking! (err, yeah, I'm
> talking virtual functions here).
No you'll have to whack on me some more. It's best for you to introduce a
subtle bug that you know I'll track down (i.e. put it in vhosts and then
nobody else will touch it ;)... a subtle bug that when found I'll realize
"oh duh, virtual functions solve this problem!" ;)
Dean
Re: Apache 2.0, NSPR, C++, ...
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Sun, 21 Jun 1998, Ben Laurie wrote:
>
> > Good question: I'm only interested in exploring whether C++ is a
> > sensible option for 2.0 (or 3.0 or 2.26 or whatever). I only set up the
> > Apache++ list because I was approached by people too nervous to discuss
> > it here because of the amount of heat it generated.
> >
> > I'd like to see the concept explored but do not currently have the time
> > or energy to do it single-handed.
>
> Yeah I would like to see that too.
>
> > Whatever happens, I would like to see a nice C++ interface for 2.0, but
> > I suppose that is also in the air.
>
> I'm in favour of C++ being used as a "better type checker than C". If
> it's feasible. After finding that mod_usertrack bug that was a result of
> strchr() "losing" the const I'm sold on the idea. Maybe that means we'll
> need a few #ifdef __cplusplus sections in .h files which declare things
> slightly differently for C++ and for C... it's similar to the GNUC
> __attribute__s I've put in for printf-style warnings and whatnot.
OK, now we're talking! Note that in C++ it is possible to have two
strchr()s - one const, one non-const, without having to mess with three
zillion (oh, OK, I exaggerate - two in this case, but for strcmp() it
would be four, and so on) different names for each function.
If you can also stomach the idea of using C++ as a "better way to keep
lists of functions than C" then we're really cooking! (err, yeah, I'm
talking virtual functions here).
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Re: Apache 2.0, NSPR, C++, ...
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 21 Jun 1998, Ben Laurie wrote:
> Good question: I'm only interested in exploring whether C++ is a
> sensible option for 2.0 (or 3.0 or 2.26 or whatever). I only set up the
> Apache++ list because I was approached by people too nervous to discuss
> it here because of the amount of heat it generated.
>
> I'd like to see the concept explored but do not currently have the time
> or energy to do it single-handed.
Yeah I would like to see that too.
> Whatever happens, I would like to see a nice C++ interface for 2.0, but
> I suppose that is also in the air.
I'm in favour of C++ being used as a "better type checker than C". If
it's feasible. After finding that mod_usertrack bug that was a result of
strchr() "losing" the const I'm sold on the idea. Maybe that means we'll
need a few #ifdef __cplusplus sections in .h files which declare things
slightly differently for C++ and for C... it's similar to the GNUC
__attribute__s I've put in for printf-style warnings and whatnot.
Dean
Re: Apache 2.0, NSPR, C++, ...
Posted by Ben Laurie <be...@algroup.co.uk>.
Dean Gaudet wrote:
>
> On Fri, 19 Jun 1998, Rasmus Lerdorf wrote:
>
> > I think everybody has been avoiding this can of worms. But it needs to be
> > discussed. To me the biggest question is whether your apache-nspr and
> > Ben's apache++ (or whatever it is known as) can co-exist or do we have to
> > decide on one over the other?
>
> NSPR could be used with C++ ... Ben can correct me, but I think what he
> wants to do with apache-plusplus is to develop something that is
> distinctly C++ and still highperformance/etc. I don't know if that's on
> the 2.0 time frame or not. The list has been dead lately.
Good question: I'm only interested in exploring whether C++ is a
sensible option for 2.0 (or 3.0 or 2.26 or whatever). I only set up the
Apache++ list because I was approached by people too nervous to discuss
it here because of the amount of heat it generated.
I'd like to see the concept explored but do not currently have the time
or energy to do it single-handed.
Whatever happens, I would like to see a nice C++ interface for 2.0, but
I suppose that is also in the air.
Certainly the current thinking seems to be that NSPR is a good basis for
either a C or C++ 2.0.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/
Apache 2.0, NSPR, C++, ...
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 19 Jun 1998, Rasmus Lerdorf wrote:
> I think everybody has been avoiding this can of worms. But it needs to be
> discussed. To me the biggest question is whether your apache-nspr and
> Ben's apache++ (or whatever it is known as) can co-exist or do we have to
> decide on one over the other?
NSPR could be used with C++ ... Ben can correct me, but I think what he
wants to do with apache-plusplus is to develop something that is
distinctly C++ and still highperformance/etc. I don't know if that's on
the 2.0 time frame or not. The list has been dead lately.
> I haven't looked closely enough at the nspr code to figure out what the
> thread-abstraction is going to do to my module architecture.
NSPR has multiple models of operation... and each interacts with third
party stuff slightly differently. (This is just for Unix, NT has no
problems/caveats that I'm aware of.) In theory, and I haven't verified
this completely, if you use NSPR as a set of wrappers for pthreads then
you can interact with any thread-aware/thread-safe library without
trouble. In this case it's fine for any thread to block on i/o because it
is a pthread and pthreads are allowed to do that.
If you use NSPR in its most portable form -- where it uses no native
threads, then third party libraries can't be used unless they do no I/O.
They have to be ported to NSPR in order for things to work right with I/O.
>From looking at the library I've been pretty happy that both forms should
work on any unix with pthreads. The portable form should work on
essentially any unix -- although I can imagine running into kernel bugs
with select/etc.
> Basically, since I don't see any other alternatives we may as well move
> forward and say that apache-nspr is the basis of Apache2.
There are other alternatives, I'm just not as impressed with them. As far
as I know, no other C threading abstraction has an initial set of ports so
large. NSPR works already on 20 some odd unixes, plus WIN32 (plus mac and
win31 I suppose, with caveats). I believe IBM has an OS/2 port that isn't
released, although there are groups working on a free port. There's an
amiga port under way... (These are actually ports of mozilla, NSPR will
probably be finished early on.)
> One really ignorant question though. Is the NSPR code the same code
> Netscape uses in their Enterprise Server product? If so, I am a tad weary
> because I have had loads of reliability problems that look like threading
> problems to me with those servers.
>From what I understand (the netscape guys are here on new-httpd still I
think so they could answer better), NSPR in some form is used in their
enterprise server. But I don't think it's the same library that they
released -- the released one is "nsprpub", for public I presume.
Reliability is something we can solve though, if in fact it is a problem.
If I just look at the library as an abstract interface to I/O, threading,
and other OS primitives I see nothing that scares me. I see why a lot of
things are the way they are... and I can envision how the under workings
should work. I have looked at the under workings and the code style is
very pleasing. It is an excellent piece of work.
It's the sort of thing that I dreaded we would have to write. There are
holes in NSPR's coverage of portability issues. I mention the ones I've
run into in the README.NSPR and NSPR.foo files in the apache-nspr tarball.
Some of them make sense to solve within NSPR, and some make sense to solve
in apache. (Some examples are filename manipulation, user/group/auth
details, some missing pieces in process creation...) I'm excited about
using and extending NSPR to meet our needs.
Dean
Re: [PATCH] Fixing ap_escape_quotes
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> Yup we all probably agree on that... the question becomes: do we do it in
> 1.3.x or do we do it in 2.0? I wouldn't mind seeing it in apache-nspr...
> I wouldn't mind seeing apache-nspr as the basis for 2.0 work. I haven't
> heard any complaints about that concept... or maybe I'm just ignoring them
> :)
>
> If enough folks agree that apache-nspr is the basis for 2.0 work then I
> could commit it and the fun can start. A game plan would be nice though
> :)
I think everybody has been avoiding this can of worms. But it needs to be
discussed. To me the biggest question is whether your apache-nspr and
Ben's apache++ (or whatever it is known as) can co-exist or do we have to
decide on one over the other?
>From my perspective as a module writer I really would prefer not to have
my hand forced into using a C++ API. I couldn't care less what the core
Apache code is written in, but unless someone can clearly identify some
major benefits I would prefer to be able to build my module.a or module.so
with a standard C compiler. This major benefit may be the fact that it is
easier to deal with multiple threads in C++ than it is in C, so in that
sense apache-nspr and apache++ might be a good fit, and if a standard C
module API is going to be much clunkier than a C++ one, I may have to
reluctantly take the C++ bullet in the back of the head.
I haven't looked closely enough at the nspr code to figure out what the
thread-abstraction is going to do to my module architecture. But it is
something that I need to look at anyway in order to get an NSAPI version
of the module running on Unix. Under NT TLS does the trick and with a bit
of flex-hacking it now spits out TLS-friendly parsers, so I am not too
concerned about MT on NT.
Basically, since I don't see any other alternatives we may as well move
forward and say that apache-nspr is the basis of Apache2.
One really ignorant question though. Is the NSPR code the same code
Netscape uses in their Enterprise Server product? If so, I am a tad weary
because I have had loads of reliability problems that look like threading
problems to me with those servers.
-Rasmus
Re: [PATCH] Fixing ap_escape_quotes
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 19 Jun 1998, Alexei Kosut wrote:
> IIRC, the NULL pool has special meaning when given to the pool code, so
> that might be a bad idea.
I curse the meaning it has... make_sub_pool will make a pool that has no
parent... which in every case I've seen it used has lead to a memory leak
on restart. I removed this "feature" in apache-nspr.
> What's the big deal about having code use pools? It's still "httpd
> neutral", it just needs alloc.c and alloc.h. Which are nearly entirely
> independent of Apache. Just make the pool stuff part of libap. That's
> probably a good idea anyway.
Yup we all probably agree on that... the question becomes: do we do it in
1.3.x or do we do it in 2.0? I wouldn't mind seeing it in apache-nspr...
I wouldn't mind seeing apache-nspr as the basis for 2.0 work. I haven't
heard any complaints about that concept... or maybe I'm just ignoring them
:)
If enough folks agree that apache-nspr is the basis for 2.0 work then I
could commit it and the fun can start. A game plan would be nice though
:)
> Or use alloca. But I think we had that discussion already... ;)
doesn't work -- you need to pass the pointer back, alloca memory is
destroyed on function exit.
Dean
Re: [PATCH] Fixing ap_escape_quotes
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Fri, 19 Jun 1998, Marc Slemko wrote:
> On Thu, 18 Jun 1998, Rodent of Unusual Size wrote:
>
> > I'd like to get the attached patch (or a version of it) into 1.3.1.
> > The main thing it does is make libap httpd-neutral again, so other
> > things (like stuff in src/support) can use libap routines without
> > dragging in a lot of httpd-specific crud. I'd just commit this,
> > but it changes MMN because it alters the ap_escape_quotes()
> > semantics.
>
> One way around this would be to just use malloc() if a NULL pool
> is passed in. This could be applied more generally to allow for
> use of functions where a pool isn't available in some bastard
> situation.
IIRC, the NULL pool has special meaning when given to the pool code, so
that might be a bad idea.
What's the big deal about having code use pools? It's still "httpd
neutral", it just needs alloc.c and alloc.h. Which are nearly entirely
independent of Apache. Just make the pool stuff part of libap. That's
probably a good idea anyway.
Or use alloca. But I think we had that discussion already... ;)
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: [PATCH] Fixing ap_escape_quotes
Posted by Marc Slemko <ma...@worldgate.com>.
On Thu, 18 Jun 1998, Rodent of Unusual Size wrote:
> I'd like to get the attached patch (or a version of it) into 1.3.1.
> The main thing it does is make libap httpd-neutral again, so other
> things (like stuff in src/support) can use libap routines without
> dragging in a lot of httpd-specific crud. I'd just commit this,
> but it changes MMN because it alters the ap_escape_quotes()
> semantics.
One way around this would be to just use malloc() if a NULL pool
is passed in. This could be applied more generally to allow for
use of functions where a pool isn't available in some bastard
situation.
But I'm not sure iti s a good idea.