Re: cvs commit: apr/include apr_lib.h
On Sun, Feb 11, 2001 at 11:31:04PM -, [EMAIL PROTECTED] wrote: > wrowe 01/02/11 15:31:04 > > Modified:.CHANGES >passwd apr_getpass.c >include apr_lib.h > Log: > result(?) What result? Stop mauling the size_t arg and overwrite the > system buffer before returning from apr_password_get, and clean up doc. >... > --- apr_lib.h 2001/02/11 00:12:11 1.51 > +++ apr_lib.h 2001/02/11 23:31:04 1.52 > @@ -220,12 +220,12 @@ >/** > * Display a prompt and read in the password from stdin. > * @param prompt The prompt to display > - * @param pwbuf Where to store the password > - * @param bufsize The length of the password string. > + * @param pwbuf Buffer to store the password > + * @param bufsize The length of the password buffer. > * @deffunc apr_status_t apr_password_get(const char *prompt, char *pwbuf, > size_t *bufsize) > */ >APR_DECLARE(apr_status_t) apr_password_get(const char *prompt, char > *pwbuf, > - size_t *bufsize); > + size_t *bufsize); Um... couldn't that bufsize just be an apr_size_t rather than "size_t *" ?? If you aren't going to return a value, then drop the indirection, right? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/passwd apr_getpass.c
On Sun, Feb 11, 2001 at 11:35:07PM -, [EMAIL PROTECTED] wrote:
>...
> --- apr_getpass.c 2001/02/11 23:32:11 1.12
> +++ apr_getpass.c 2001/02/11 23:35:07 1.13
> @@ -215,12 +215,10 @@
>APR_DECLARE(apr_status_t) apr_password_get(const char *prompt, char
> *pwbuf, size_t *bufsiz)
>{
>char *pw_got = getpass(prompt);
> -if (strlen(pw_got) > (*bufsiz - 1)) {
> - *bufsiz = ERR_OVERFLOW;
> -memset(pw_got, 0, strlen(pw_got));
> -return APR_ENAMETOOLONG;
> -}
>apr_cpystrn(pwbuf, pw_got, *bufsiz);
>memset(pw_got, 0, strlen(pw_got));
> +if (strlen(pw_got) >= *bufsiz) {
> +return APR_ENAMETOOLONG;
> +}
>return APR_SUCCESS;
>}
Would it make sense to not return a partial password, if it is too long? For
example, change the function to:
{
char *pw_got = getpass(prompt);
apr_size_t len = strlen(pw_got);
if (len < bufsize)
apr_cpystrn(pwbuf, pw_got, bufsize);
memset(pw_got, 0, len);
if (len >= bufsize) {
return APR_ENAMETOOLONG;
}
return APR_SUCCESS;
}
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/strings apr_strings.c
On Sun, Feb 11, 2001 at 09:40:04AM -0800, Cliff Woolley wrote:
>
> --- [EMAIL PROTECTED] wrote:
> > +APR_DECLARE(void *) apr_memdup(apr_pool_t *a, const void *m, apr_size_t
> > n)
> > +{
> > +void *res;
> > +
> > +if(m == NULL)
> > + return NULL;
> > +res = apr_palloc(a, n);
> > +memcpy(res, m, n);
> > +return res;
> > +}
> > +
>
> Nice. Minor question, though: why is this called "apr_memdup" instead of
> "apr_pmemdup"?
> I thought all of the "like the standard function, but into a pool instead of
> the heap"
> functions were prefixed with a 'p'.
You're right. I've just changed it.
> Also, should it check for failure of apr_palloc, or is that being too anal?
We never check for failure to alloc. The program terminates instead.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/strings apr_strings.c
Yup. Done and checked in.
[ I'm checking usage right now to ensure people don't depend on that... ]
Cheers,
-g
On Sun, Feb 11, 2001 at 04:32:19PM +, Ben Laurie wrote:
> Hmmm. Actually, this could improve its efficiency by only allocating
> len+1 bytes if len < n. Should we do that?
>
> Cheers,
>
> Ben.
>
> [EMAIL PROTECTED] wrote:
> >
> > ben 01/02/11 08:25:08
> >
> > Modified:strings apr_strings.c
> > Log:
> > ap_pstrndup could have caused out-of-bounds memory accesses (this is a
> > theoretical problem that I happened to notice). Only lightly tested.
> >
> > Revision ChangesPath
> > 1.9 +7 -2 apr/strings/apr_strings.c
> >
> > Index: apr_strings.c
> > ===
> > RCS file: /home/cvs/apr/strings/apr_strings.c,v
> > retrieving revision 1.8
> > retrieving revision 1.9
> > diff -u -r1.8 -r1.9
> > --- apr_strings.c 2001/02/11 16:18:09 1.8
> > +++ apr_strings.c 2001/02/11 16:25:07 1.9
> > @@ -83,13 +83,18 @@
> >APR_DECLARE(char *) apr_pstrndup(apr_pool_t *a, const char *s,
> > apr_size_t n)
> >{
> >char *res;
> > +size_t len;
> >
> >if (s == NULL) {
> >return NULL;
> >}
> >res = apr_palloc(a, n + 1);
> > -memcpy(res, s, n);
> > -res[n] = '\0';
> > +len = strlen(s);
> > +if(len > n) {
> > + memcpy(res, s, n);
> > + res[n] = '\0';
> > +} else
> > + memcpy(res, s, len+1);
> >return res;
> >}
> >
> >
> >
> >
>
> --
> http://www.apache-ssl.org/ben.html
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/include apr_lib.h
[ bringing back to list; OtherBill apparently misfired the reply ] On Sun, Feb 11, 2001 at 09:37:31PM -0600, William A. Rowe, Jr. wrote: > From: "Greg Stein" <[EMAIL PROTECTED]> > Sent: Sunday, February 11, 2001 8:05 PM > > > > > wrowe 01/02/11 15:31:04 > > > > > > Modified:.CHANGES > > >passwd apr_getpass.c > > >include apr_lib.h > > > Log: > > > result(?) What result? Stop mauling the size_t arg and overwrite the > > > system buffer before returning from apr_password_get, and clean up > > > doc. > > > >APR_DECLARE(apr_status_t) apr_password_get(const char *prompt, char > > > *pwbuf, > > > - size_t *bufsize); > > > + size_t *bufsize); > > > Um... couldn't that bufsize just be an apr_size_t rather than "size_t *" ?? > > If you aren't going to return a value, then drop the indirection, right? > > Absolutely apr_size_t. And that is a question, do we want to return the > actual > size needed/used? I personally don't care, but wasn't going to make that call > when I was fixing the fn (returned 0 before, rather useless.) So I'd agree in > part, either apr_size_t bufsize, or apr_size_t *bufsize returning the size > used > or needed (len as returned by getpass). I don't think we need to return the size. The caller can always use strlen() if that is needed. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/passwd apr_getpass.c
[ bringing back to list; OtherBill apparently misfired the reply ]
On Sun, Feb 11, 2001 at 09:42:02PM -0600, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <[EMAIL PROTECTED]>
> Sent: Sunday, February 11, 2001 8:09 PM
> >
> > Would it make sense to not return a partial password, if it is too long? For
> > example, change the function to:
> >
> > if (len < bufsize)
> > apr_cpystrn(pwbuf, pw_got, bufsize);
> > memset(pw_got, 0, len);
> > if (len >= bufsize) {
> > return APR_ENAMETOOLONG;
> > }
>
> six of one, half dozen of the other to me. But we need to document the
> behavior
> (I believe it implies that we return partial results, which is why I fixed the
> code the way that I did.)
If the password was incomplete, then it will be useless. It just means that
we'll end up with a (partial) copy of the password sitting in memory for no
purpose. I'm up for not copying it unless we have a valid one.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/include apr.hw
> This is what was scaring me BTW. I have rolled three times this week, and > each time there has been some OS that didn't work. The first time it was > OS/2, then BeOS, now Windows. It seems to me that because we aren't > freezing the tree and asking people to work on stabilizing the code, we > are likely to continue to hit this problem. The big problem is that we > have four very different platforms, and it is too easy to accidentally > break one when fixing another. That is a problem, but it is a problem > that we aren't fixing right now, so not asking for some sort of code > freeze is going to continue to cause these problems IMHO. Ryan, the problem is that you are making significant changes that effect builds (moving prototypes and creating new header files) and then tagging the tree before verifying that it builds on the major platforms. Of course that isn't going to work. Freezing the tree won't help. There is no reason to tag the tree just after you have made a change that is likely to affect other platforms. Wait until after it has been built by others, or get Sam to make his tinderbox software available for automated build checks. What not freezing does affect is the probability that someone *other* than the RM may make a significant change just prior to the tag. Personally, I never encountered that problem as RM. BTW, when I said that we needed to build more often, I meant once a week at most. Otherwise, people won't feel it is important to test the last build. Roy
Re: cvs commit: apr/include apr.hw
> > This is what was scaring me BTW. I have rolled three times this week, and > > each time there has been some OS that didn't work. The first time it was > > OS/2, then BeOS, now Windows. It seems to me that because we aren't > > freezing the tree and asking people to work on stabilizing the code, we > > are likely to continue to hit this problem. The big problem is that we > > have four very different platforms, and it is too easy to accidentally > > break one when fixing another. That is a problem, but it is a problem > > that we aren't fixing right now, so not asking for some sort of code > > freeze is going to continue to cause these problems IMHO. > > Ryan, the problem is that you are making significant changes that > effect builds (moving prototypes and creating new header files) and then > tagging the tree before verifying that it builds on the major platforms. Take a second look. The first tag was three days after the scoreboard change that broke OS/2. The second was almost a week after (the same scoreboard change is what broke BeOS), the third change is the only one that was done immediately following a major change, and that was only after I had two people tell me to go ahead and tag, and since I wanted to test my script, I did. > What not freezing does affect is the probability that someone *other* > than the RM may make a significant change just prior to the tag. > Personally, I never encountered that problem as RM. > > BTW, when I said that we needed to build more often, I meant once a week > at most. Otherwise, people won't feel it is important to test the > last build. As I said when I started this, I was going to roll multiple times, to help get the process correct. If I had tagged and rolled once a week, then the process would have taken three weeks to get down. As it is, I believe we have got the process after one week. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: apr_sockaddr_ip_get is missing
[ please send APR issues to dev@apr.apache.org; new-httpd is for the web server. ] The error below is because network_io/unix/sockaddr.c was not rebuilt. It wasn't changed in the big rename, but it includes sa_common.c (which *did* change). I imagine it would work if you had dependencies set up in APR, but the easiest is to just rm network_io/unix/sockaddr.lo and rebuild APR. Once sockaddr is rebuilt with the new sa_common, then the new function will be present. Cheers, -g On Mon, Feb 12, 2001 at 11:00:05AM +0100, Daniel Stenberg wrote: > Hi > > While trying to build subversion, linking fails due to a missing > apr_sockaddr_ip_get function. Said to be first referenced in > apr/.libs/libapr.a(apr_snprintf.o). > > I just updated my sources from CVS, this might of course not be a problem if > there's another checkin in the pipe... > > -- > Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77 >ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol > -- Greg Stein, http://www.lyra.org/
Re: Poliicy proposal.
[EMAIL PROTECTED] writes: > I would like to suggest that ANY project with a committer on the list can > tag the tree at any time. Those tags should be in a format like > APACHE_2_0 or SUBVERSION_X_Y. When APR releases a tarball, we will use > APR_X_Y, which will allow people to easily distinguish why the tag was > added. +1. But don't expect to see SUBVERSION_X_Y tags for a while... :-)
Re: Poliicy proposal.
[EMAIL PROTECTED] writes: > I would like to suggest that ANY project with a committer on the list can > tag the tree at any time. Those tags should be in a format like > APACHE_2_0 or SUBVERSION_X_Y. When APR releases a tarball, we will use > APR_X_Y, which will allow people to easily distinguish why the tag was > added. This sounds very useful to me. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Poliicy proposal.
Jeff Trawick <[EMAIL PROTECTED]> writes: > > I would like to suggest that ANY project with a committer on the list can > > tag the tree at any time. Those tags should be in a format like > > APACHE_2_0 or SUBVERSION_X_Y. When APR releases a tarball, we will use > > APR_X_Y, which will allow people to easily distinguish why the tag was > > added. > > This sounds very useful to me. +1
Re: Poliicy proposal.
On 12 Feb 2001, Karl Fogel wrote: > Jeff Trawick <[EMAIL PROTECTED]> writes: > > > I would like to suggest that ANY project with a committer on the list can > > > tag the tree at any time. Those tags should be in a format like > > > APACHE_2_0 or SUBVERSION_X_Y. When APR releases a tarball, we will use > > > APR_X_Y, which will allow people to easily distinguish why the tag was > > > added. > > > > This sounds very useful to me. > > +1 That's either three or four (I didn't really count), so I'll update the web page with this information. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Feature request realpath(3) wrapper
Hi All, In doing some work for Subversion, I came accross a need to convert relative pathnames to absolute pathnames. Now realpath works under Linux, but I am told it is broken under some versions of Solaris (although it works for 2.5), and doesn't exist under win32(although there is _fullpath). I have no idea about BeOS. Is this something that anyone on the APR team would like to implement in a nice portable fashion? -- > Kevin Pilch-Bisson [EMAIL PROTECTED] http://www.pilch-bisson.net PGP Public Key At http://pgp.pilch-bisson.net pgp7E9PDwZvgp.pgp Description: PGP signature
Re: Feature request realpath(3) wrapper
Hm This could be very interesting. Let's throw this into the STATUS file, and see who picks it up. I believe this will also be handled by Will Rowe's canonical filename stuff, but I would need him to reply to be absolutely sure. Ryan On Mon, 12 Feb 2001, Kevin Pilch-Bisson wrote: > Hi All, > > In doing some work for Subversion, I came accross a need to convert > relative pathnames to absolute pathnames. Now realpath works under > Linux, but I am told it is broken under some versions of Solaris > (although it works for 2.5), and doesn't exist under win32(although > there is _fullpath). I have no idea about BeOS. > > Is this something that anyone on the APR team would like to implement in > a nice portable fashion? > > -- > > > Kevin Pilch-Bisson > [EMAIL PROTECTED] > http://www.pilch-bisson.net > PGP Public Key At http://pgp.pilch-bisson.net > ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: Poliicy proposal.
> Those tags should be in a format like > APACHE_2_0 or SUBVERSION_X_Y. I find this weird. Library providers are not supposed to know such things about thier clients. It's the job the clients to record what version of the library they are dependent upon. Surely this tag is just an attempt to defer the day when the apr clients have to do this? Think MODULE_MAGIC_NUMBER... - ben
Re: Poliicy proposal.
On Mon, 12 Feb 2001, Ben Hyde wrote: > > > Those tags should be in a format like > > APACHE_2_0 or SUBVERSION_X_Y. > > I find this weird. Library providers are not supposed to know such > things about thier clients. It's the job the clients to record what > version of the library they are dependent upon. Surely this tag is just > an attempt to defer the day when the apr clients have to do this? Think > MODULE_MAGIC_NUMBER... The problem I am trying to solve, is that there are currently two projects that are driving development of APR, which means that both are using HEAD of the APR tree. Neither project can really use another tag, because they are driving the development, and thus need to be on the cutting edge. When one of those projects wants to make a release, they need to be able to reproduce that release easily. I believe 99% of the apr clients will use a simple tag from the APR tree, but those that must be on the cutting edge will always find that hard to do. I am trying to make this as easy as possible. That's my goal anyway. I expect that when APR actually makes a beta or release version, then a good portion of this problem will go away. This would also be easier if Apache and Subversion didn't ask the developers to check out APR, but instead kept a copy of the tree in their repositories. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: Poliicy proposal.
[EMAIL PROTECTED] wrote: > On Mon, 12 Feb 2001, Ben Hyde wrote: > > > APACHE_2_0 or SUBVERSION_X_Y. > > > > I find this weird still > The problem I am trying to solve, hear hear > as easy as possible. it's weird for tags in apr to named after user's projects. > kept a copy of the tree in their repositories. or the symbolic equivalent of that. if a customer needs apr to do (what ever you want to call it, freeze, release, tag, varnish) then apr should. meanwhile the apr using code should be paranoid at compile & runtime about what version of apr they are associating with. sequential fast moving build numbers are good for this. - ben
Re: Feature request realpath(3) wrapper
In the works :-)
Re: Poliicy proposal.
Ben Hyde <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > > On Mon, 12 Feb 2001, Ben Hyde wrote: > > > > APACHE_2_0 or SUBVERSION_X_Y. > > > > > > I find this weird > > still [...] > > as easy as possible. > > it's weird for tags in apr to named after user's projects. [...] > meanwhile the apr using code should be paranoid > at compile & runtime about what version of apr > they are associating with. > > sequential fast moving build numbers are good > for this. I agree with Ben. What's the problem with doing another tag of APR whenever one of the two projects driving development needs a tag for its own build? -- Daniel Rall
Re: cvs commit: apr/file_io/unix dir.c
> trawick 01/02/12 12:55:34 > > Modified:file_io/unix dir.c > Log: > OS/390 has _POSIX_PATH_MAX but not PATH_MAX (did I hear a little bird > say "APR_PATH_MAX?") Yes... the 'right' fix would be good here.
Re: Feature request realpath(3) wrapper
On Mon, Feb 12, 2001 at 01:38:10PM -0500, Kevin Pilch-Bisson wrote: > Hi All, > > In doing some work for Subversion, I came accross a need to convert > relative pathnames to absolute pathnames. Now realpath works under > Linux, but I am told it is broken under some versions of Solaris > (although it works for 2.5), and doesn't exist under win32(although > there is _fullpath). I have no idea about BeOS. Just for the sake of info, it doesn't appear the BeOS provides anything of this sort at all. sam th [EMAIL PROTECTED] http://www.abisource.com/~sam/ GnuPG Key: http://www.abisource.com/~sam/key pgpLVLUF9B0gG.pgp Description: PGP signature
Re: cvs commit: apr/file_io/unix dir.c
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes: > > trawick 01/02/12 12:55:34 > > > > Modified:file_io/unix dir.c > > Log: > > OS/390 has _POSIX_PATH_MAX but not PATH_MAX (did I hear a little bird > > say "APR_PATH_MAX?") > > Yes... the 'right' fix would be good here. This should be pretty simple... apr.hw: Move this code from include/arch/win32/fileio.h to apr.hw but also add any needed includes (what are they?): #if APR_HAS_UNICODE_FS /* An arbitrary size that is digestable. True max is a bit less than 32000 */ #define APR_PATH_MAX 8192 #define APR_FILE_MAX MAX_PATH #else /* !APR_HAS_UNICODE_FS */ #define APR_PATH_MAX MAX_PATH #define APR_FILE_MAX MAX_PATH #endif apr.h.in: include sys/limits.h and limits.h then #if defined(PATH_MAX) #define APR_PATH_MAX PATH_MAX #elif defined(_POSIX_PATH_MAX) #define APR_PATH_MAX _POSIX_PATH_MAX #else #error Fix APR_PATH_MAX for your platform. #endif -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: Poliicy proposal.
On Mon, Feb 12, 2001 at 01:04:16PM -0800, Daniel Rall wrote: > Ben Hyde <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] wrote: > > > On Mon, 12 Feb 2001, Ben Hyde wrote: > > > > > APACHE_2_0 or SUBVERSION_X_Y. > > > > > > > > I find this weird > > > > still > [...] > > > as easy as possible. > > > > it's weird for tags in apr to named after user's projects. > [...] > > meanwhile the apr using code should be paranoid > > at compile & runtime about what version of apr > > they are associating with. > > > > sequential fast moving build numbers are good > > for this. > > I agree with Ben. What's the problem with doing another tag of APR > whenever one of the two projects driving development needs a tag for > its own build? APR does not (yet) have its own independent release system. It is not yet formally released with its own version numbers and labelling. As a further result, none of the clients are including APR based on a tarball. They all refer directly to the HEAD and release the APR sources bundled directly in. Any tags that the clients are placing on the APR tree are merely commentary. Something along the lines of "we snapped a release right ". If somebody wants to take a bit of time and turn the APR release mechanics into a formal system, then we can start adjusting the Apache and SVN release systems to say "we chose APR 1.0.7 for this release of ". Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/dso/os390 Makefile.in dso.c
Actually, the correct solution is for somebody to hit up every one of those Makefile.in and remove the INCLUDES line. That stuff can all go into rules.mk.in. Cheers, -g On Mon, Feb 12, 2001 at 08:46:01PM -, [EMAIL PROTECTED] wrote: > trawick 01/02/12 12:46:00 > > Modified:dso/os390 Makefile.in dso.c > Log: > standardize the include path in the OS/390 dso directory to get rid of an > annoying warning message > > Revision ChangesPath > 1.5 +3 -1 apr/dso/os390/Makefile.in > > Index: Makefile.in > === > RCS file: /home/cvs/apr/dso/os390/Makefile.in,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -u -r1.4 -r1.5 > --- Makefile.in 2001/01/09 11:05:42 1.4 > +++ Makefile.in 2001/02/12 20:45:58 1.5 > @@ -5,6 +5,8 @@ >@INCLUDE_RULES@ > >INCDIR=../../include > -INCLUDES=-I$(INCDIR) -I$(INCDIR)/arch > +OSDIR=$(INCDIR)/arch/@OSDIR@ > +DEFOSDIR=$(INCDIR)/arch/@DEFAULT_OSDIR@ > +INCLUDES=-I$(INCDIR) -I$(OSDIR) -I$(DEFOSDIR) > ># DO NOT REMOVE > > > > 1.7 +1 -1 apr/dso/os390/dso.c > > Index: dso.c > === > RCS file: /home/cvs/apr/dso/os390/dso.c,v > retrieving revision 1.6 > retrieving revision 1.7 > diff -u -r1.6 -r1.7 > --- dso.c 2001/02/08 07:44:33 1.6 > +++ dso.c 2001/02/12 20:45:59 1.7 > @@ -53,7 +53,7 @@ > */ > >#include "apr_strings.h" > -#include "os390/dso.h" > +#include "dso.h" >#include >#include > > > > -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/file_io/unix dir.c
From: "Jeff Trawick" <[EMAIL PROTECTED]> Sent: Monday, February 12, 2001 3:42 PM > apr.hw: > > Move this code from include/arch/win32/fileio.h to apr.hw but also add > any needed includes (what are they?): > > #if APR_HAS_UNICODE_FS > /* An arbitrary size that is digestable. True max is a bit less than > 32000 */ > #define APR_PATH_MAX 8192 > #define APR_FILE_MAX MAX_PATH > #else /* !APR_HAS_UNICODE_FS */ > #define APR_PATH_MAX MAX_PATH > #define APR_FILE_MAX MAX_PATH > #endif The MAX_PATH comes from windows.h, which is included right off the top in apr.hw. > apr.h.in: > > include sys/limits.h and limits.h then > > #if defined(PATH_MAX) > #define APR_PATH_MAX PATH_MAX > #elif defined(_POSIX_PATH_MAX) > #define APR_PATH_MAX _POSIX_PATH_MAX > #else > #error Fix APR_PATH_MAX for your platform. > #endif > > -- > Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: >http://www.geocities.com/SiliconValley/Park/9289/ > Born in Roswell... married an alien... >
