On 4 Dec 2004 23:40:37 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: pquerna
> Date: Sat Dec 4 15:40:37 2004
> New Revision: 109832
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=109832
> Log:
> * test/testfile.c: Add a test for apr_file_writev().
> * file_io/unix/readwrite.c
On Fri, 3 Dec 2004 20:31:56 +, Joe Orton <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 03, 2004 at 12:09:23PM -0500, Jeff Trawick wrote:
> > On Wed, 1 Dec 2004 19:30:43 +, Joe Orton <[EMAIL PROTECTED]> wrote:
> ...
>
>
> > > But the trade-off is also
On Wed, 1 Dec 2004 19:30:43 +, Joe Orton <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 01, 2004 at 09:36:32AM -0500, Jeff Trawick wrote:
>
>
> > HP-UX apparently has no other function than getpass(), and it silently
> > truncates after 8 characters. There are
HP-UX apparently has no other function than getpass(), and it silently
truncates after 8 characters. There are Apache httpd and Subversion
users grappling with this limit. (It caused a some puzzlement for me
with cvs too, but APR won't help that ;) )
The hint from Joe is to set ac_cv_func_getpas
On Wed, 1 Dec 2004 12:04:14 +, Joe Orton <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 30, 2004 at 10:11:02AM -0500, Jeff Trawick wrote:
>
>
> > On 30 Nov 2004 14:41:33 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > apr_password_get(): Fix the chec
On Tue, 30 Nov 2004 10:26:31 -0500 (EST), Cliff Woolley
<[EMAIL PROTECTED]> wrote:
> On Tue, 30 Nov 2004, Jeff Trawick wrote:
>
>
>
> > > * @param pwbuf Buffer to store the password
> > > * @param bufsize The length of the password buffer.
> > >
On 30 Nov 2004 14:41:33 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> apr_password_get(): Fix the check for buffer overflow.
> --- apr/apr/trunk/include/apr_lib.h (original)
> +++ apr/apr/trunk/include/apr_lib.h Tue Nov 30 06:41:31 2004
> @@ -168,6 +168,8 @@
> * @param prompt The
On Mon, 22 Nov 2004 11:34:10 +0100, Uwe Zeisberger
<[EMAIL PROTECTED]> wrote:
> Joe Orton wrote:
> > Here's what I propose to fix this, anything I'm missing?
it makes sense to me
On Thu, 18 Nov 2004 17:22:50 +0100, Uwe Zeisberger
<[EMAIL PROTECTED]> wrote:
> Below comes a log and a patch. I assume, that apr_xlate_conv_buffer
> should convert inbuf and assume, that the strings ends then. Else its
> use in test/testxlate.c is not appropriate.
it was assumed that the applica
On Tue, 16 Nov 2004 07:02:47 +, Joe Orton <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 15, 2004 at 11:09:40PM +, Julian Foad wrote:
> > Remove unnecessary type casts that were casting away "const".
> > No functional change.
>
> These ones aren't unnecessary, some compilers are more picky about
On Thu, 04 Nov 2004 18:11:41 +0530, gaurav <[EMAIL PROTECTED]> wrote:
> Does apr have any explisit support for writing http clients?
No. There is an Apache httpd sub-project which uses apr services to
provide some help for http clients, described at
http://httpd.apache.org/apreq/
On Sun, 10 Oct 2004 09:12:53 +0200, Dror Shilo <[EMAIL PROTECTED]> wrote:
> > Incidentally, will "apr_os_thread_current( )" work on all platforms
> > (specifically, Linux and Win32)? Am I understanding this correctly to mean
> > that the function works on all platforms, but the return value is
> >
On Fri, 8 Oct 2004 15:08:38 +0100, Joe Orton <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, Oct 08, 2004 at 09:58:07AM -0400, Allan Edwards wrote:
> > Joe Orton wrote:
> > >>The fact that these casts are unnecessary can be tracked using comments,
> > >>a list of issues in STATUS, or, not wishing to roc
On Tue, 05 Oct 2004 14:02:20 -0400, Allan Edwards <[EMAIL PROTECTED]> wrote:
> > I'm like Jeff, I won't lose any sleep if we just say that
> > 64 bit APR 1.0 cannot handle very large memory objects and go
> > the path of validating restricting and casting. At least let's
> > pursue that path and se
On Sun, 3 Oct 2004 19:52:36 -0600, David Barrett <[EMAIL PROTECTED]> wrote:
> Is the function "apr_pollset_poll( )" supposed to block, even on
> non-blocking sockets? I ask because I would like it to, even though it
> appears to not. The docs say this about the function:
>
> Block for ac
On Wed, 29 Sep 2004 19:06:04 -0700, Bennett, Tony - CNF
<[EMAIL PROTECTED]> wrote:
> Jeff,
>
> Here's my /etc/netsvc.conf:
> hosts=local=auth,bind4
>
> I used this to prevent hitting on my DNS server for IPV6 Addresses
> when we specify APR_UNSPEC, since we are not currently using IPV6
>
On Wed, 29 Sep 2004 23:00:52 +0100, Joe Orton <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 29, 2004 at 05:35:34PM -0400, Allan Edwards wrote:
> > In order to eliminate the following warnings for Win64 builds the
> > appended patch is needed. However this changes fields in the apr_memnode_t
> > structur
On Thu, 30 Sep 2004 16:53:02 +0530, Gaurav Gupta
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Am getting this error when creating executable for my code for a socket
> server programme. Kindly help.
I don't think this is the right way to do it, but it does seem to
work. If somebody with the appropriate
On Wed, 29 Sep 2004 20:14:41 -0600, David Barrett <[EMAIL PROTECTED]> wrote:
> Sockets are coming along, but I can't find a portable way of distinguishing
> between a failed or empty "apr_socket_recv( )" on a non-blocking socket.
> Here's what I'm currently doing:
>
> # rv = apr_socket_recv( s, ..
On Wed, 29 Sep 2004 20:18:36 -0400, Jeff Trawick <[EMAIL PROTECTED]> wrote:
> On Wed, 29 Sep 2004 14:55:40 -0700, Bennett, Tony - CNF
> <[EMAIL PROTECTED]> wrote:
> > Note: I posted a similar question on comp.unix.aix
> >
> > Platform: Aix 5.1
> >
> >
On Wed, 29 Sep 2004 14:55:40 -0700, Bennett, Tony - CNF
<[EMAIL PROTECTED]> wrote:
> Note: I posted a similar question on comp.unix.aix
>
> Platform: Aix 5.1
>
> We are using Apache 2.0.42. We have written a module
> which calls apr_sockaddr_info_get() which, in turn,
> performs a getaddrinfo()
On 28 Sep 2004 16:16:17 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> clar2004/09/28 09:16:17
>
> Modified:file_io/win32 readwrite.c
>include apr.hnw apr.hw
>network_io/win32 sendrecv.c
> Log:
> replaced define for DWORD_MAX with APR_DWORD
On 23 Sep 2004 06:17:59 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> mturk 2004/09/22 23:17:59
>
> Modified:threadproc/win32 Tag: APR_0_9_BRANCH thread.c
> Log:
> Backport from HEAD.
> Makes the threads to behave like on posix. If the thread is created without
> APR_DE
On 9 Sep 2004 05:22:38 -, meenal binwade
<[EMAIL PROTECTED]> wrote:
>
>
> hi,
> I am trying to build APR 0.9.4 on AIX 5.1 m/c using xlc version 5
> compiler.but on doing a ./configure i get the following error message:
>
> checking build system type... powerpc-ibm-aix5.1.0.0
> checking ho
On Fri, 27 Aug 2004 13:00:07 +0200, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Jeff Trawick wrote:
>
> >>The win version now makes sure that the calling tread does
> >>not remain under impersonated user if something goes wrong.
> >
> >
> > it seems ve
On Fri, 27 Aug 2004 10:30:17 +0200, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Discussing with wrowe, I've changed the patch a bit.
> The apr_proc_attr_user_set is now visible on all platforms,
> and on most of them it is ENOTIMPL.
> The unix version uses apr_uid_get to obtain the uid and gi
-- Forwarded message --
From: Jeff Trawick <[EMAIL PROTECTED]>
Date: Tue, 3 Aug 2004 14:45:16 -0400
Subject: Re: [PROOF-OF-CONCEPT?] logging memory used by an allocator
To: Sander Striker <[EMAIL PROTECTED]>
On Sun, 1 Aug 2004 19:46:14 +0200, Sander Striker <[
this never showed up for some reason???
--- Begin Message ---
A couple of questions come up from an application perspective:
am I leaking memory? if so, on what operation?
how much memory does it take to perform a certain operation?
If the application can find out how much heap memory is presently
A couple of questions come up from an application perspective:
am I leaking memory? if so, on what operation?
how much memory does it take to perform a certain operation?
If the application can find out how much heap memory is presently owned by a
certain allocator, it can be easier to address su
On 22 Jul 2004 01:48:35 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> stoddard2004/07/21 18:48:35
>
> Modified:.CHANGES
===
> RCS file: /home/cvs/apr/CHANGES,v
> retrieving revision 1.483
> retrieving
Jim Jagielski wrote:
apr_snprintf(buf, 5, "%3d ", (int) size);
if (buf[3] != ' ') { /* catch overflow */
return strcpy(buf, "");
}
If I understand the problem correctly, doesn't snprintf() return
the number of bytes that would have been printed if there had been
no limit. Thus, can't we che
Joe Orton wrote:
On Wed, Jun 30, 2004 at 06:00:29AM -0400, Jeff Trawick wrote:
IMHO the original version is sufficient for now.
Agreed.
Adding tests seems like the best way to protect against someone screwing
up in the future...
yes, that makes perfect sense to me
David Reid wrote:
[EMAIL PROTECTED] wrote:
wrowe 2004/06/28 11:09:16
Modified:strings Tag: APR_0_9_BRANCH apr_strings.c
Log:
Avoid any edge case or clib bug that might result in a string
overflow of the fixed 5-byte buffer for our size function.
Returns the '' string when
[EMAIL PROTECTED] wrote:
wrowe 2004/06/28 11:09:16
Modified:strings Tag: APR_0_9_BRANCH apr_strings.c
Log:
Avoid any edge case or clib bug that might result in a string
overflow of the fixed 5-byte buffer for our size function.
Returns the '' string when the buffer wo
David Reid wrote:
Well, while my original plan was to tag last night, then roll today, the
offer of beer was made last night so the roll didn't happen :-)
However, there are now 2 tarballs available at http://cvs.apache.org/~dreid/
which I rolled in the last 30 minutes. They represent the initial o
jean-frederic clere wrote:
Hi,
Find enclosed a patch that allows to parse xml documents encoded in
EBCDIC (OSD_EBCDIC_DF04_1). Some days ago I already committed the need
include files:
xml/expat/lib/map_osd_ebcdic_df04_1.h and xml/expat/lib/osd_ebcdic_df04_1.h
Any comments?
just a dumb question.
[EMAIL PROTECTED] wrote:
clar2004/06/14 12:36:59
Modified:include apr_thread_proc.h
Log:
Fixed typo in API description
Revision ChangesPath
1.108 +1 -1 apr/include/apr_thread_proc.h
Index: apr_thread_proc.h
=
[EMAIL PROTECTED] wrote:
clar2004/06/14 10:26:20
Modified:include apr_thread_proc.h
include/arch/netware apr_arch_threadproc.h
threadproc/beos proc.c
threadproc/netware proc.c
threadproc/os2 proc.c
threadproc/
Joe Orton wrote:
On Mon, Jun 14, 2004 at 08:22:41AM -0400, Jeff Trawick wrote:
Joe Orton wrote:
So, I'm proposing that _POSIXSEM or _PROC_PTHREAD should never be made
the default locking mechanism. Nothing to stop those who understand the
trade-off making an informed choice, of course.
gene
Brad Nicholes wrote:
Is there a reason why the apr_procattr APIs were implemented as
apr_procattr_xxx_set (apr_procattr_t*, value)
rather than
apr_procattr_set (apr_procattr_t*, APR_xxx_ATTR, value, ...)
that's before my time, but I'd guess:
preserves typechecking on values
Joe Orton wrote:
So, I'm proposing that _POSIXSEM or _PROC_PTHREAD should never be made
the default locking mechanism. Nothing to stop those who understand the
trade-off making an informed choice, of course.
generally +1, though I'm concerned that Solaris may not have a good default due
to the sy
some look like easy cleanups for platform folks to look at more closely; others
are just accepted incompatibilities with our general philosophy (e.g., instead
of defining apr_strcasecmp() we ensure that Unix-ish strcasecmp() is available
everywhere)
1) possible future binary compatibility conce
Rodent of Unusual Size wrote:
is it just me, or is there something legitimately wrong here:
#include
#include "apr.h"
#include "apr_time.h"
#include
int main(int argc, char *argvp[])
{
apr_time_exp_t lt;
apr_time_exp_lt(<, (apr_time_now() / APR_USEC_PER_SEC));
printf("is_dst=%d\n", l
(should have sent this to the list originally)
--- Begin Message ---
Brad Nicholes wrote:
We considered that but decided that adding a NetWare only enum was
less intrusive than adding a NetWare only API to APR. I'm fine with it
either way, this just seemed a little cleaner. All of the other enu
[EMAIL PROTECTED] wrote:
clar2004/06/11 13:13:19
Modified:include apr_thread_proc.h
Log:
Added NetWare specific option in apr_cmdtype_e to start program in a separate address space for cmdtype field in apr_procattr_t struct
Revision ChangesPath
1.106 +7 -4 ap
Joe Orton wrote:
On Fri, Jun 11, 2004 at 11:42:19AM -0400, Jeff Trawick wrote:
whether or not the envionment is inherited should be orthogonal to some
other details of starting the program (via shell, searching or not
searching PATH), but API does not reflect that
I need a way to start the new
whether or not the envionment is inherited should be orthogonal to some other
details of starting the program (via shell, searching or not searching PATH),
but API does not reflect that
I need a way to start the new process via the shell *and* inherit the
environment of the calling process, but
Albert Chin wrote:
Why add -qHALT=E to CFLAGS on AIX (build/apr_hints.m4)? That seems
like an undue burden.
It forces the client application to work with
-qHALT=E. I don't see an equivalent restriction for Solaris
(-errwarn), HP-UX (+We), Tru64 UNIX (-msg_error), etc. Subversion, for
examp
Paul Querna wrote:
On Thu, 2004-06-03 at 06:27 -0400, Jeff Trawick wrote:
Who is going to do anything about these showstoppers and when? If no action, I
don't see why they should be considered showstoppers.
Another Place to Look is Bugzilla:
http://issues.apache.org/bugzilla/buglis
Who is going to do anything about these showstoppers and when? If no action, I
don't see why they should be considered showstoppers.
From the STATUS file:
RELEASE 1.0 SHOWSTOPPERS:
* apr_global_mutex_child_init and apr_proc_mutex_child_init aren't
portable. There are a variety of problems
Ed Holyat wrote:
Is the apr_global_mutex.. api available for Solaris and Linux?
sure; APR won't build without selecting and calling some native system
primitive for that
For me, the apr status is returning that apr_global_mutex_.. is not
implemented on solaris2.8, redhat 2 and 3 enterpri
Joe Orton wrote:
On Tue, May 18, 2004 at 04:58:14PM -0400, Jeff Trawick wrote:
Previously we went through this mess on older Mac OS X (DNS queries only?)
I just realized that the glibc shipping with RHAS 2.1 and 3.0 (and surely
many other Linux distros) has a problem with getnameinfo() for IPv4
Joe Orton wrote:
On Tue, May 18, 2004 at 04:58:14PM -0400, Jeff Trawick wrote:
Previously we went through this mess on older Mac OS X (DNS queries only?)
I just realized that the glibc shipping with RHAS 2.1 and 3.0 (and surely
many other Linux distros) has a problem with getnameinfo() for IPv4
Previously we went through this mess on older Mac OS X (DNS queries only?)
I just realized that the glibc shipping with RHAS 2.1 and 3.0 (and surely many
other Linux distros) has a problem with getnameinfo() for IPv4-mapped address
for something defined in host file but not in DNS.
The configure
André Malo wrote:
* André Malo <[EMAIL PROTECTED]> wrote:
* Joe Orton <[EMAIL PROTECTED]> wrote:
Thanks for the patch and thanks for nagging :) I committed it with
conditional use of S_ISVTX since POSIX doesn't require that one.
Hm. Is it possible to port it back to 0.9 as well?
anyone?
done fin
André Malo wrote:
* André Malo <[EMAIL PROTECTED]> wrote:
* Joe Orton <[EMAIL PROTECTED]> wrote:
Thanks for the patch and thanks for nagging :) I committed it with
conditional use of S_ISVTX since POSIX doesn't require that one.
Hm. Is it possible to port it back to 0.9 as well?
anyone?
sure, I'
Greg Hudson wrote:
On Fri, 2004-04-30 at 18:58, Joe Orton wrote:
On Thu, Apr 29, 2004 at 10:44:16AM -0400, Jeff Trawick wrote:
wow
is there any chance you can merge your test case into the existing test
suite?
Index: file_io/os2/seek.c
Index: file_io/unix/seek.c
Index: file_io/win32/seek.c
Index
Greg Hudson wrote:
APR's handling of seeks to APR_END in buffered files has a sign error.
I've included a patch (see the end), and a test case.
wow
is there any chance you can merge your test case into the existing test suite?
André Malo wrote:
*shrug* I'd commit it myself, but I don't have sufficient karma.
committed
[EMAIL PROTECTED] wrote:
ben 2004/04/11 11:10:49
Modified:hooksTag: APU_0_9_BRANCH apr_hooks.c
Log:
Make the topological sort pull out-of-order items to the front, instead of
pushing them to the back. This makes things stay where they want to be better.
Don't these several c
Joe Orton wrote:
On Tue, Mar 30, 2004 at 03:51:34PM +0100, Joe Orton wrote:
On Tue, Mar 30, 2004 at 09:25:30AM -0500, Jeff Trawick wrote:
here's a more concrete example
apr HEAD
RHEL 3.0 for PPC
libtool 1.4.3 from system install
CFLAGS="-Xcompiler -m64" LDFLAGS="-Xcompiler -m64
Joe Orton wrote:
On Tue, Mar 30, 2004 at 09:25:30AM -0500, Jeff Trawick wrote:
here's a more concrete example
apr HEAD
RHEL 3.0 for PPC
libtool 1.4.3 from system install
CFLAGS="-Xcompiler -m64" LDFLAGS="-Xcompiler -m64 -Xlinker -melf64ppc" \
./configure
Isn't tha
here's a more concrete example
apr HEAD
RHEL 3.0 for PPC
libtool 1.4.3 from system install
CFLAGS="-Xcompiler -m64" LDFLAGS="-Xcompiler -m64 -Xlinker -melf64ppc" \
./configure
it builds, test programs work, but apr-config just has -pthread for CFLAGS and
nothing for LDFLAGS
but in build/apr_rul
Joe Orton wrote:
On Tue, Mar 30, 2004 at 07:05:22AM -0500, Jeff Trawick wrote:
[EMAIL PROTECTED] wrote:
jorton 2004/03/30 01:58:22
Modified:xlatexlate.c
Log:
* xlate/xlate.c (check_sbcs): Remove function which made unsafe
assumptions (a theoretical issue), and was buggy in not
[EMAIL PROTECTED] wrote:
jorton 2004/03/30 01:58:22
Modified:xlatexlate.c
Log:
* xlate/xlate.c (check_sbcs): Remove function which made unsafe
assumptions (a theoretical issue), and was buggy in not resetting the
iconv handle on failure (the cause of at least one real issue).
(has anybody else seen this?)
Ben Laurie wrote:
Jeff Trawick wrote:
We could make the 2.0.x version require mod_unique_id.
that seems very reasonable
solution 4: add some suitable API to APR 0.9 and implement on all
platforms
Surely not returning the value from the inc is broken anyway? And a
harmless change even if you
André Malo wrote:
* Jeff Trawick <[EMAIL PROTECTED]> wrote:
André Malo wrote:
* Jeff Trawick <[EMAIL PROTECTED]> wrote:
somehow I doubt there will be any problems at all getting it approved, but
nobody acted as a champion thus far and asked for approval themselves
In fact, I'
Joe Orton wrote:
Can APR just hard-code a couple of EBCDIC<->something translation tables
(#ifdef I_AM_EBCDIC) to solve these problems? I'd be suprised if the
iconv() adds that much overhead vs the translation table, if you're
going to do the iconv_open() anyway.
I won't worry about that for now;
Perhaps you set LDFLAGS to something. build/apr_rules.mk has that setting for
LDFLAGS. But the setting of LDFLAGS in apr-config does not have that setting.
Is this for a reason?
(Trying to get apr-config --ldflags to spit out an option required for building
an app compatible with the apr build
Nick Kew wrote:
On Wed, 24 Mar 2004, Jeff Trawick wrote:
Sometimes people report bugs and/or post patches on these lists and for
whatever reason they are never properly addressed. Discussion on the list is
great, but it is all too easy for the e-mails move out of sight. The mail
arrives all too
Joe Orton wrote:
Thanks, added that too with the configure check for sendfilev64. Take 3
is about ready to be committed, I think.
I can't imagine any showstoppers at this point. Committing real soon seems to
be the right thing to do.
TODO:
* test the sendfile thunks work
* adjust ssize_t rc han
Sometimes people report bugs and/or post patches on these lists and for
whatever reason they are never properly addressed. Discussion on the list is
great, but it is all too easy for the e-mails move out of sight. The mail
arrives all too quickly. The best action you can take to avoid the bit
Jeff Trawick wrote:
Joe Orton wrote:
Updated patch attached, thanks for the feedback so far...
TODO:
* hook up Solaris sendfilev64 if necessary
looks necessary... dunno if there was a Solaris with sendfilev but no
sendfilev64 such that we'd have to thunk... for now I have this just for
pl
Joe Orton wrote:
Updated patch attached, thanks for the feedback so far...
TODO:
* hook up Solaris sendfilev64 if necessary
looks necessary... dunno if there was a Solaris with sendfilev but no
sendfilev64 such that we'd have to thunk... for now I have this just for
playing in the Solaris sendfi
Joe Orton wrote:
On Mon, Mar 22, 2004 at 09:16:02AM -0500, Jeff Trawick wrote:
Joe Orton wrote:
- what to do about old Linux 2.2's which have no sendfile64(): disable
sendfile support, or disable LFS support? both change the ABI
from an ABI standpoint (given that there is no 1.0 ABI yet), it
Joe Orton wrote:
So it seems no optimisation is really possible here; what performance
problem is this code solving? The overhead of iconv surely in
iconv_open() anyway: I think the right thing to do is remove the
check_sbcs() functions.
On z/OS, where charset translation is a key feature of most
Joe Orton wrote:
A concrete proposal... the two requirements are:
1. APR 1.0 should support large files on Unix systems which have a
32-bit off_t but support the LFS standard
and
2. APR must not export -D_FILE_OFFSET_BITS=64 by default to get a 64-bit
off_t, since this breaks the ABI of any other
Joe Orton wrote:
APR 0.9.x can't change the size of apr_off_t, but it's still useful to
be able to use O_LARGEFILE in a few specific cases on LFS platforms when
the application knows it is safe: to allow writing >2Gb log files in
particular. It's not safe to use in general, since {f,l,}stat() will
Joe Orton wrote:
Hmm. Is this sbcs thing really safe at all? Just because a character
set translation gives a particular mapping for 0x00-0xff in that order
why is it guaranteed that it will for any other ordering of bytes?
e.g. invent a mapping which does "0xff " -> "0xff" but "0xff 0xf1"
-> "
Guenter Knauf wrote:
Hi,
I'm against immediate adoption of SVN for purely community-based
reasons, but not for technical reasons. I believe that switching to SVN
will raise the bar to entry for new contributors, and I think we
should do whatever we can do to try and lower this bar. Unfortunately
on
Joe Orton wrote:
The convset->ich is set up to convert from UTF-8 to ISO-8895-1;
check_sbcs fails to create the sbcs table for this case, of course. But
the iconv state is not reset, and it was by design left part-way through
a UTF-8 sequence: so when a subsequent conv_buffer calls come along to
r
Charles, Steve wrote:
I am investigating using APR on z/OS (OS 390) and have a few questions.
1) Where can I find an OS390 version of APR.h ?
build apr on your box and you get apr.h customized for your level of the OS
Please see http://www.apache.org/~trawick/apache-2-on-zos.html. The
instructio
Spinka, Kristofer wrote:
Has anyone tried to use getaddrinfo with the AI_V4MAPPED flag (perhaps even
OR'd with AI_ALL) and the family set to AF_INET6? From what I gleaned from
a brief look at httpd, the consumer in question, it appears as though
IPv4-mapped addressing is used in general.
I haven't
Joe Orton wrote:
Was the conclusion to this thread to not change APR?
I thought the conclusion was that "my" boxes were special ;)
There do seem to
be lots of 11i boxes "out there" which have got into the state where
getaddrinfo is found in libc but non-functional.
hmmm...
If Madhu says that geta
related trivia for Solaris users: the folks at www.blastwave.org were kind
enough to add ssl support to their subversion package this weekend...
previously it was not useful for accessing the test repository
Klaus Keppler wrote:
[RESENT because I got no response for about two weeks...]
fine to report/discuss here but if no response in that period of time it is
very likely that it has scrolled off the radar
please report the problem via the bug database at
http://issues.apache.org/bugzilla/index.html
Nick Kew wrote:
Rationale: if an module gets a resource that proves to be bad (e.g.
a connection that's gone away), it shouldn't be returned to the
pool to be given out again. We should invalidate it.
I'm proposing the following patch, though I'm not sure whether
or not we should free_container in
Guenter Knauf wrote:
Hi,
On Fri, Mar 12, 2004 at 07:25:49PM +0100, Sander Striker wrote:
I hereby would like to propose that we move APR to the Subversion
repository at http://svn.apache.org/repos/asf/.
-1
I'm against immediate adoption of SVN for purely community-based
reasons, but not for techn
Aaron Bannert wrote:
On Fri, Jan 02, 2004 at 03:09:09AM +, Nick Kew wrote:
Rationale: if an module gets a resource that proves to be bad (e.g.
a connection that's gone away), it shouldn't be returned to the
pool to be given out again. We should invalidate it.
I'm proposing the following patch,
[EMAIL PROTECTED] wrote:
dreid 2004/03/09 09:57:35
Modified:.Makefile.in
Log:
This seems to have been lost in the changeover. If there is another
way of accomplishing this then I failed to find one and the code
in configure seems to point at this being a simple oversight
William A. Rowe, Jr. wrote:
At 04:14 PM 3/1/2004, Jeff Trawick wrote:
[EMAIL PROTECTED] wrote:
trawick 2004/03/01 13:05:44
threadproc/win32 thread.c
1.56 +14 -2 apr/threadproc/win32/thread.c
Index: thread.c
William A. Rowe, Jr. wrote:
At 03:05 PM 3/1/2004, [EMAIL PROTECTED] wrote:
trawick 2004/03/01 13:05:44
Add apr_threadattr_stacksize_set() for overriding the default
stack size for threads created by apr_thread_create().
Tell us - does this really scale?
If you mean "is this a perfect abstract
[EMAIL PROTECTED] wrote:
trawick 2004/03/01 13:05:44
threadproc/win32 thread.c
1.56 +14 -2 apr/threadproc/win32/thread.c
Index: thread.c
===
RCS file: /home/cvs/apr/threadproc/win32/thread.c,v
Jeff Trawick wrote:
In case it isn't obvious, there is a dependency problem that some make
implementations complain about. Here is Solaris make:
I forgot I had Sascha's patch on this box too... please keep moving, ignore
the slobbering fool
In case it isn't obvious, there is a dependency problem that some make
implementations complain about. Here is Solaris make:
$ make
make: Warning: Infinite loop: Target `include/apr_pools.h' depends on itself
Current working directory /export/home/trawick/apache/apr
make: Warning: Infinite loop:
Justin Erenkrantz wrote:
--On Tuesday, February 24, 2004 12:37 PM -0500 Jeff Trawick
<[EMAIL PROTECTED]> wrote:
Perhaps the default build should disable any features which could make
the
licensing of the generated "product" different than the licensing of the
source code, an
Justin Erenkrantz wrote:
However, this *might* mean issues for downstream participants who
package apr-util; that in and of itself, might cause us to remove GDBM
support, but it's not because of any licensing issues. If we're not
comfortable allowing third-parties to create GPLd code out of AL
Sascha Schumann wrote:
Here is a new adaption of gen-build.py, including the config
files.
This works fine for me on Solaris. On z/OS (a.k.a. OS/390), I hit various make
warnings about circular dependencies with includes. After deleting all the
rules for .h file dependencies (and discov
Sascha Schumann wrote:
Should I assume that this is broken on the same platforms where
gen-build.py is broken (where a mix of unix and system-specific
code is used)?
The shell script uses similar logic, so I am afraid it might
have similar issues as well. I suppose you refer to this
r
901 - 1000 of 1860 matches
Mail list logo
