From: Ian Holsman [EMAIL PROTECTED]
Sent: Tuesday, May 22, 2001 4:35 PM
hi guys.
just updated my CVS and I noticed 2 things (on Win32)
the custom build of gen_uri_delims seems not to be being done.
I'm on this
it's compliaing about not finding strcasecmp
News to me, I'll look at it.
No concerns here!
Cheers,
-g
On Tue, May 22, 2001 at 07:28:30AM -0400, Jeff Trawick wrote:
Apache has a couple of modules* which call strtok(), breaking thread
safety on most platforms. I'd prefer to suck in FreeBSD's strtok.c,
rename strtok_r() to apr_strtok(), and remove the cruft.
APR
Greg Stein wrote:
On Tue, May 22, 2001 at 07:28:30AM -0400, Jeff Trawick wrote:
Apache has a couple of modules* which call strtok(), breaking thread
safety on most platforms. I'd prefer to suck in FreeBSD's strtok.c,
rename strtok_r() to apr_strtok(), and remove the cruft.
APR already
Well, now that the uri stuff is now in apr-util, the biggest one left
(IMHO) is util_date.c. My plan is to come up with a similar series of
patches for apr_date.h. Should a new directory be used (date)? I also
have some additional formats that don't quite fit the HTTP RFC, but that
I saw in the
Greg Stein wrote:
On Mon, May 21, 2001 at 06:45:05PM -0700, Roy T. Fielding wrote:
On Sun, May 20, 2001 at 06:52:18PM -0700, Greg Stein wrote:
Since gen_uri_delims.lo is not destined for a library (.la), then it
can/should simply use the .o suffix. That will also prevent the object
From: Ben Collins-Sussman [EMAIL PROTECTED]
Sent: Tuesday, May 22, 2001 8:44 AM
OK, it's not actually a patch, because I'm not sure where it ought to
live. I've attached it below.
The function apr_dir_remove() won't work on a non-empty directory, so
this routine fills the gap. It's
Greg Stein [EMAIL PROTECTED] writes:
This should be in the Apache coding style before committing. Notably: no
space between symbol and opening paren, braces on the if/else lines, and the
return status lines on a separate line.
Oh, you mean the exact *opposite* of GNU / Subversion coding
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
My personal preference is that the remove continues to run, leaving only
droppings it can't remove. Nothing irks me more than fixing the 'one file'
that couldn't be removed, only to trip over the next one on the next pass.
And save the first
Hello!
Like some others I have a problem with connecting the tomcat 4 (beta 4 or 5)
with the apache 1.3.19.
The computer is a solaris 8 (sparc) system with jdk1.3 and a gcc compiler
I could successfully compile a mod_webapp.so file.
Although after copying it to the apache/libexec folder and
From: Ben Collins-Sussman [EMAIL PROTECTED]
Sent: Wednesday, May 23, 2001 9:17 AM
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
My personal preference is that the remove continues to run, leaving only
droppings it can't remove. Nothing irks me more than fixing the 'one file'
that
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
I agree. I'm thinking of rewriting it to leave files behind. I
suspect the routine could return either APR_SUCCESS (if nothing but
was left behind), or some not-yet-invented error code that
specifically means it wasn't able to remove
From: Ben Collins-Sussman [EMAIL PROTECTED]
Sent: Wednesday, May 23, 2001 10:31 AM
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
I agree. I'm thinking of rewriting it to leave files behind. I
suspect the routine could return either APR_SUCCESS (if nothing but
was left behind), or
Of course it's implemented. Please Revert. If you want to add a note at
the code where it ought to be implemented, please do, not in the header...
The whole point is that _any_ platform can choose not to implement a given
field. Win32 and OS2 already populate that field, and Unix will if you
Markus Mailinglists wrote:
Hello!
Like some others I have a problem with connecting the tomcat 4 (beta 4 or 5)
with the apache 1.3.19.
The computer is a solaris 8 (sparc) system with jdk1.3 and a gcc compiler
I could successfully compile a mod_webapp.so file.
Although after copying it to
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
What if 3 different files in the tree (scattered about) are
un-removable for different reasons? This function still removes
everything else and finishes its recursion. Which of the three status
codes should it return?
The first it
From: Ben Collins-Sussman [EMAIL PROTECTED]
Sent: Wednesday, May 23, 2001 11:35 AM
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
What if 3 different files in the tree (scattered about) are
un-removable for different reasons? This function still removes
everything else and finishes
Some eager person may wish to replace the strchr() calls with inline
code. The only compiler I'm really familiar with w.r.t. code
generation will replace strchr() with inline code but I suspect that
is not the case with most compilers.
Macros decided not to play nice.
If this works for
I was trying to figure where it is best documented. Certainly in the structure
definition itself, since folks will land there from the apr_dir_read, or
apr_fstat,
or apr_get_file_info.
Bill
- Original Message -
From: Ben Collins-Sussman [EMAIL PROTECTED]
To: William A. Rowe, Jr.
Some eager person may wish to replace the strchr() calls with inline
code. The only compiler I'm really familiar with w.r.t. code
generation will replace strchr() with inline code but I suspect that
is not the case with most compilers.
Macros decided not to play nice.
If
On Wed, May 23, 2001 at 06:47:16PM +0200, jean-frederic clere wrote:
Hi,
I am planning to add two new error codes to apr_errno.h for apr-iconv:
APR_EILSEQ Illegal byte sequence
Already exists, APR_EBADCH
APR_E2BIG Too big (It can be used also for Arg list too long).
Already
Hi,
Could apr_int8_t and apr_uint8_t be added for completeness?
And I noticed that there aren't any functions like:
hton16(), hton32(), hton64() and ntoh16(), ntoh32(), ntoh64().
Is there any reason not to add these (they can be simple
defines)? It is somewhat of a recurring thing that one
On Wed, May 23, 2001 at 09:17:57AM -0500, Ben Collins-Sussman wrote:
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
...
Does it make sense to apply some lstat check against the tree, such that
Nope.
symlinks' targets aren't blown away? I'm not clear if your patch protects
that or not.
On Wed, May 23, 2001 at 03:33:29PM -0400, Victor J. Orlikowski wrote:
Some eager person may wish to replace the strchr() calls with inline
code. The only compiler I'm really familiar with w.r.t. code
generation will replace strchr() with inline code but I suspect that
is not
At 06:21 PM 05/23/2001, Greg Stein wrote:
On Wed, May 23, 2001 at 09:17:57AM -0500, Ben Collins-Sussman wrote:
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
Does it make sense to apply some lstat check against the tree,
such that
symlinks' targets aren't blown away? I'm not clear if your
24 matches
Mail list logo
