On Wed, 17 Aug 2005, Joe Orton wrote:
On Tue, Aug 16, 2005 at 01:49:55AM -0500, William Rowe wrote:
At 09:24 PM 8/15/2005, Garrett Rooney wrote:
So back in Dec 2003 Sander Striker suggested [1] adding Subversion's
macros for manipulating apr arrays (APR_ARRAY_IDX, which automates the
On Mon, 25 Jul 2005, Wilson, Brian A wrote:
I'm trying to track down an error when closing a program using apr. In
the jxta-c shell it calls apr_terminate upon exit but it ends up in an
infinite while loop in apr_allocator_destroy. I've traced it down to a
point where the while loop is
On Wed, 20 Jul 2005, Paul Querna wrote:
-1 for Win32, the condvars deadlock is a serious bug. I knew this is not
news, but as the patch had been available for quite a while, is it
possible to get it fixed?
No.
I will not commit such a platform specific patch. Anyone who actually
On Tue, 12 Jul 2005, Dan Johnson wrote:
The problem is that I need to compile using MinGW under Cygwin, and
MinGW doesn't provide any of the shared memory header files (shm.h,
sys/mmap.h, sys/mman.h, etc.) so the test fails.
A quick Google shows that a few other people have had this problem
On Thu, 26 May 2005, Daniel Rall wrote:
* apr/include/apr_thread_proc.h
(apr_thread_data_set): Corrected spelling of the word thread.
Got it, thanks!
On Tue, 12 Apr 2005, Paul Querna wrote:
I believe APR 0.9.x is under CTR.
I was also under the impression that all branches of APR were CTR.
However, I agree that discussion on API changes would be good, even in a
CTR system. That has always been the basic idea with CTR -- you can
commit
On Thu, 31 Mar 2005, Sander Striker wrote:
Ryan Bloom wrote:
I really don't think we should take a function like apr_pcalloc and
convert it to a macro. The only reason to go to a macro is for
performance reasons. First, the performance boost should be
relatively minimal, and for
On Tue, 22 Mar 2005, Marco Spinetti wrote:
I'd like to know the download and upload speed of clients with my server.
Can use some apr functions toknow these statistics?
I assume you're talking about Apache 2.0.x. If so, then it's the httpd
that you'll need to query for statistics like this,
On Fri, 18 Mar 2005, Ryan Bloom wrote:
disabling sendfile solved it immediately. Seems to me that until our
sendfile support is better, we should err on the side of always
sending the data correctly instead of absolutely as fast as possible.
I would much rather have APR default to not using
On Thu, 17 Mar 2005, Justin Erenkrantz wrote:
he rolled it, I get 1 vote. Not 3. This is an absolute violation
of our charter and operating guidelines.
With that, the counter is at four hours, and I will pull
down this apr-iconv tarball unless the vote concludes
in favor of this
On Thu, 17 Mar 2005, Paul Querna wrote:
When I counted the votes, I interpreted all of the +1s to be for the
entire group (apr, apr-util, apr-iconv). I am sorry if I misinterpreted
any of the votes. This was not my intention.
This is, I think, the real question, and one I was asking myself.
On Thu, 17 Mar 2005, Jim Jagielski wrote:
Anyway, anyone who has ever been an RM has done something
to tick people off, it comes with the job ;)
amen to that...
On Thu, 17 Mar 2005, William A. Rowe, Jr. wrote:
If you two (and anyone else with an explicit vote on the apr-iconv
1.0.2 tarball) vote in the next hour it would clarify things quite
a bit.
My original vote was intended to be +1 for release. Apparently such a
vote at this point is of little
@@ -46,6 +46,13 @@
apr_bucket_alloc_t *list = data;
apr_allocator_free(list-allocator, list-blocks);
+
+#if APR_POOL_DEBUG
+if (list-pool list-allocator != apr_pool_allocator_get(list-pool))
{
+apr_allocator_destroy(list-allocator);
+}
+#endif
+
On Sun, 27 Feb 2005, Luca Renzi wrote:
I'm a student and I need to use apr_lib for a little
project.
The question is:
I don't understand what are data and key parameter for
the function
apr_socket_data_set.
Could somebody explain?
Several APR data types include a userdata member that is
On Fri, 18 Feb 2005, Damir Dezeljin wrote:
I'm developing an application using APR on AS/400 (OS400) platform. As I
know only apr (no apr-utils) was ported to OS400 by IBM to run Apache2. Do
anyone know if there is any issue on compiling apr-utils on OS400?
apr-util is supposed to all be code
On Sun, 30 Jan 2005, Nick Kew wrote:
If anyone with APR karma would like to take responsibility for committing
it, please contact me within 24 hours to discuss logistics.
This was me dropping the ball, and the problem is being corrected...
On Thu, 20 Jan 2005, Ben Hyde wrote:
The mnemonic b is widely used for both buckets and brigades.
Sometimes e means bucket. :)
Buckets and brigades both have a field named list, but one is a
doubly linked list and the other is one of the many flavors of heap.
heh
I don't think anybody
On Thu, 20 Jan 2005, Ben Hyde wrote:
Should not the second argument to apr_brigade_create be named
bucket_alloc, rather than list.
It was supposed to mean freelist. It got its name before we came up
with a name for the bucket allocator (cleverly named bucket_alloc).
In other words, sure, go
On Mon, 27 Dec 2004, Garrett Rooney wrote:
This seems to defeat the point of having an APR_SUCCESS in the first
place. It's also (at least in my eyes) slightly less intuitive than
explicit testing.
Part of the definition of apr_status_t is the fact that APR_SUCCESS is
defined to be zero.
On Mon, 27 Dec 2004, Garrett Rooney wrote:
Ok, I think we may be talking about two different cases...
There's the check if a call returned an error, and if so return that to
your caller case, which personally I think is easist to read as:
if (rv)
return rv;
No, that's just me mixing up
On Mon, 27 Dec 2004, Mihai Limbasan wrote:
In reply to my earlier question - went ahead and did it.
What this patch does is fix all conditionals that depend implicitely
on APR_SUCCESS being zero to perform an explicit test against its
*macro definition* and not against the numeric literal or
On Wed, 15 Dec 2004, Brad Nicholes wrote:
release of APR 1.0. Since then there has been a lot of activity in
TRUNK as compared to almost no activity in the 1.0.x branch.
After the 1.0.x branch was created at ApacheCon, Justin and Thom
backported everything that they thought could be
On Thu, 9 Dec 2004, Nick Kew wrote:
Why does the close function take a void arg? Can't we just pass it an
apr_dbt_t *?
To pass to apr_pool_cleanup funcs without a cast :-)
Don't do this. This is exactly the sort of thing that got us into trouble
with apr_brigade_cleanup(). In
On Thu, 9 Dec 2004, Nick Kew wrote:
If it is accepted as a startingpoint for an apr-util module, I'll
donate it to ASF and license it all under ASF terms.
If not, all rights reserved.
Concept definitely seems appealing...
On Tue, 7 Dec 2004, Stas Bekman wrote:
Well, I see why it was made like this. this is because of the cleanup
wrapper:
Originally apr_brigade_cleanup() itself was the pool cleanup callback and
thus the void* argument type was necessary. Later on it was causing
badness on Win32 due (I think) to
On Tue, 7 Dec 2004, Stas Bekman wrote:
As explained in the other reply, it's not this code that causes the crash,
but (maybe) the wrapper that calls it. The wrapper is autogenerated based
on the prototype. I have no details of the crash, I hate talking on behalf
of someone, when I don't know
On Wed, 1 Dec 2004, David Barrett wrote:
A couple questions about the XML parser built into apr_util:
1) Does it support anything other than pure ASCII files?
2) Is there any way to parse UTF-8 files?
3) Does it use the Xerces XML back end?
My understanding is that it's just a wrapper
On Tue, 30 Nov 2004, Jeff Trawick wrote:
* @param pwbuf Buffer to store the password
* @param bufsize The length of the password buffer.
+ * @remark If the password entered must be truncated to fit in
+ * the provided buffer, APR_ENAMETOOLONG will be returned.
*/
On Thu, 25 Nov 2004, Joe Orton wrote:
Or if it does, -1 veto on either bumping the APR major version or
creating a branch or making toast with jam before Allan submits a patch
for review on [EMAIL PROTECTED]
Okay, well, that means that for progress to be made, some form of patch
needs to get
On Wed, 24 Nov 2004, Allan Edwards wrote:
First order of business now that we are on SVN is to focus on
the APR changes that are needed. It's not clear to me though,
now that we have an APR 1.0 branch, is the trunk open for
API-breaking changes or do we need a separate branch for that work?
On Wed, 24 Nov 2004, William A. Rowe, Jr. wrote:
Allan - your last patches were to try to -wedge- the current
API into httpd. Can you share the patch just to fix APR?
Then we can start to comprehend scope. NO CASTS - just the
correct declarations in the first place.
Since this is obviously
On Wed, 24 Nov 2004, Garrett Rooney wrote:
I guess I'm just arguing for a single branch that's the target of the
current development, as opposed to one 64 bit dev branch and one trunk
which holds other changes, thus requiring us to either invest constant
effort in merging changes from the
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
Oh, please don't. We have *no* idea what the changes are or whether we'll
even ultimately accept them. Please branch Allen's changes off in a
sandbox (cp trunk branches/64-bit-changes) - let him get a workable version
that we can then review,
On Wed, 24 Nov 2004, Justin Erenkrantz wrote:
To be clear, I'm perfectly happy with merging to trunk in Allen's changes
*once* completed and reviewed and moving trunk to 2.x if need be - but I
Nevertheless, the question at hand is what action to take RIGHT NOW.
Let's just wait for... with no
On Wed, 24 Nov 2004, [ISO-8859-15] André Malo wrote:
As you might have noticed, I'm currently cleaning up the properties that are
left over from cvs and cvs2svn. In particular:
- removing cvs2svn:cvs-rev
- adjusting svn:executable (leaving only the real executables)
- adjusting
On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote:
Yes - I understand that this means 1.x will never be used by
httpd. Version numbers are cheap. The APR project should
become used to this, if they are active, and httpd moves at
it's normal pace, it would be easy to go through APR 2.x, 3.x,
On Mon, 22 Nov 2004, Julian Foad wrote:
Joe Orton wrote:
On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote:
+memcpy( (void*)uuid_data, (const void *)g, sizeof( uuid_t ) );
Please watch the code style, Paul!
Not sure exactly what Joe is referring to, but note that it should
On Fri, 19 Nov 2004, Garrett Rooney wrote:
We're using SVN now, might as well say so in README.dev ;-)
Got it, thanks.
On Fri, 19 Nov 2004, Garrett Rooney wrote:
In an attempt to see what happened in the last day or so while my email
was accidentally being routed to /dev/null (never mess with your email
settings right before getting on a plane, it's just asking for trouble)
I checked out the eyebrowse
On Sat, 20 Nov 2004, Justin Erenkrantz wrote:
Opinions on my '?'s above?
Looks good. -- justin
Likewise +1 to all.
--Cliff
We've taken the plunge. The APR CVS repositories are now converted and
closed.
svn co https://svn.apache.org/repos/asf/apr/apr/trunk/ apr
svn co https://svn.apache.org/repos/asf/apr/apr-util/trunk/ apr-util
svn co https://svn.apache.org/repos/asf/apr/apr-iconv/trunk/ apr-iconv
svn co
On Fri, 5 Nov 2004, Marco Spinetti wrote:
Can someone explain me the difference between apr and glib?
I see the glib doc
(http://developer.gnome.org/doc/API/2.0/glib/index.html) and it seems
very complete: it has a lot of similar apr functions.
Well, as you say, there is a lot of overlap in
On Wed, 20 Oct 2004, Brian King wrote:
I'm just wondering if this is the right list to get support for Win32
building issues.
Um, well, if you mean support for building APR on Win32 or support for
building apps with APR on Win32, then the answer is yes. If you just
need general help with
altogether.
Hope to see you there,
Cliff
T03: Apache Portable Runtime 1.0 Tutorial
Day: Sat
Time: 09h00
Session chair: None assigned
Duration: 180 minutes
Style: Tutorial
Level: Experienced
Audience: Developer
Categories:
Speaker: Cliff Woolley
Speaker: Sander Striker
As any systems programmer
On Wed, 6 Oct 2004, Jean-Jacques Clar wrote:
Why providing something that it is going to fail every single
time?
That was my original thought. I wouldn't mind seeing both the caller as
well as the !HAS_WRITEV cases fixed (or fixed if you prefer) for this
reason.
--Cliff
On Mon, 4 Oct 2004, Jean-Jacques Clar wrote:
If HAS_WRITEV is not defined the current code
will just push the first vector to the target.
Oooh, that sucks. Good catch.
The function should write all the vectors or none.
I propose the following patch, comments will be
+1, with the
On Mon, 4 Oct 2004, Jean-Jacques Clar wrote:
+if ((rv = apr_file_write(thefile, vec[i].iov_base, nbytes))
I thought that the nbytes on the call for apr_file_write() is the
number of bytes to write.
Oh crap, I'm sorry, I totally missed that. *blush*
+1 to the patch as-is.
--Cliff
On Tue, 5 Oct 2004, Joe Orton wrote:
Right, the bug is in how the function is used. It's the same as calling
apr_file_write() and presuming it won't return short. The fix is to
call apr_file_write_full(), in that case. In this case, there is no
apr_file_writev_full(), so that should be
On Thu, 23 Sep 2004, Mladen Turk wrote:
I found myself couple of times replying to the original sender
by default, while my intention was to reply to the list.
The solution is either to 'reply to all' (why would anyone
wish to receive two messages about the same subject?) or doing
that by
On Mon, 20 Sep 2004 [EMAIL PROTECTED] wrote:
ake 2004/09/20 12:20:12
Modified:atomic/win32 apr_atomic.c
Log:
WIN64: avoid unresolved external error with 64 bit build
{
+#if (defined(_M_IA64) || defined(_M_AMD64))
+return InterlockedExchangeAdd(mem, val);
Um, it sure would be helpful if the three functions:
API_DECLARE(apr_status_t) apr_iconv_open(const char *, const char *,
apr_pool_t *, apr_iconv_t *);
API_DECLARE(apr_status_t) apr_iconv(apr_iconv_t, const char **,
On Mon, 30 Aug 2004, Bill Stoddard wrote:
The apr_thread_cond code in Windows is pretty crufty stuff. I'm going
to try to find some time to do a rewrite. If I'm not done by the time
your ready to roll 1.01, then commit Klaus' patch.
Thanks, Bill!
--Cliff
On Mon, 30 Aug 2004, Gisle Vanem wrote:
Okay, I worked on the original problem and found a viable fix; Leave the
APR_INLINE in apr.hw as-is:
#define APR_INLINE __inline
But in headers like arch\win32\apr_arch_atime.h, with inline code do at
top:
#ifdef __GNUC__
#undef APR_INLINE
On Mon, 30 Aug 2004, Gisle Vanem wrote:
Did you read and understand my 1st message? Stuff like
static APR_INLINE void copy_array_hdr_core (in apr_tables.c)
wouldn't compile. I.e. becoming static extern __inline ...
Crap, I mised that detail. Anyway I find it difficult to believe that
this
On Sat, 28 Aug 2004, Gisle Vanem wrote:
Has anybody attempted building APR using MingW? The win32 portion
of the headers seems rather MSVC centric. I don't know if it's supposed
to works since I found no reference to MingW on apache.org or in the docs.
Our win32 support is indeed
On Sat, 28 Aug 2004, Klaus Keppler wrote:
As I already mentioned many many many weeks ago, the implementation
of condition variables under WIN32 has at least one nasty bug which
may lead to a deadlock
(see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27654)
Unfortunately, given our
Has anybody gotten apr-util to compile with apr-iconv?
I get the following on win32 when building apr-util with apr and apr-iconv
all present:
apr-util\xlate\xlate.c(181): error C2198: 'apr_iconv_close' : too few
arguments for call through pointer-to-function
apr-util\xlate\xlate.c(182):
On Sat, 21 Aug 2004, Anthony Wells wrote:
Currently, I am attempting to port an older Apache 1.3 module to Apache 2.0
using the APR. Unfortunately, the documentation for APR is rather sparse
The documentation, such as it is, is all in the header files. Some parts
are definitely more verbose
On Tue, 3 Aug 2004, Andrew Stribblehill wrote:
I'm trying to improve httpd's mod_userdir so that it knows it
shouldn't serve ~fool when user 'fool' has an administratively
prohibited shell, so:
UserDir DisableShell /bin/badlad
To this end, I need a function to query the user's shell. It
On Mon, 2 Aug 2004, William A. Rowe, Jr. wrote:
Least action is fork 1.1, cvs rm the offensive files, and change about
10 lines of the makefiles and rip out the ldap detection. Pretty trivial.
Deprecating means we support this junk till 2.0 releases.
+1. If the API is really that broken,
On Sun, 4 Jul 2004, David Reid wrote:
So, all being well I'll have enough net access to roll RC3 Mon/Tues. If not
I'll do it on Thursday.
Sounds good to me... thanks David!
--JustCliff
On Tue, 15 Jun 2004, Joe Orton wrote:
2) allocate brigade structures using the bucket allocator
If you're going to do this, then surely you need to call
apr_pool_cleanup_register() somewhere?
===
RCS file:
On Tue, 15 Jun 2004, Joe Orton wrote:
apr_brigade_create() does that already.
Oh, duh, of course it does. As many times as I've looked at that line,
you'd think I'd have it memorized by now. :)
On Wed, 26 May 2004, Stas Bekman wrote:
I thought that P in APR stands for Portable, but I guess it is not quite
true.
Theory and practice are more similar in theory than in practice. :)
--Cliff
On Sat, 22 May 2004, Stas Bekman wrote:
that brigade will be corrupted by this operation).
Do you suggest that the sample program that I posted doesn't hang in that
macro, but after it?
That should be correct, yes. You'll end up creating a loop in the
brigade, and walking through the
On Fri, 21 May 2004, Stas Bekman wrote:
Joe Orton wrote:
On Thu, May 20, 2004 at 03:54:58PM -0700, Stas Bekman wrote:
fb = apr_bucket_flush_create(ba);
db = apr_bucket_transient_create(aaa, 3, ba);
APR_BRIGADE_INSERT_HEAD(bb, db);
On Sun, 16 May 2004, Stas Bekman wrote:
What I'm after is having APR API specify which apr functions have errno set,
so one can rely on that and not do guessing which can change in the future.
My gut reaction is that if we actually /need/ errno to be set to glean
useful information about what
On Mon, 17 May 2004, Joe Orton wrote:
I'd hoped some friendly buckets guru would step in here :) I guess if
it's correct to solve this at bucket-level, the solution is to make
socket_bucket_read() check whether the socket is non-blocking on each
call, and temporarily set the timeout to -1 if
On Fri, 14 May 2004, Stas Bekman wrote:
So, who changed that in 2.0.49? It worked just fine pre-2.0.48. The guilty
party please stand up and explain. This change causes a serious breakage in
the protocol handlers and filters on those affected platforms. I suppose apr
doesn't have tests for
On Tue, 20 Apr 2004, Mathihalli, Madhusudan wrote:
Since I didn't get any negative feedback, can I take that it's okay to
commit the change ?
Lazy consensus would seem to apply -- so, yes. :)
On Mon, 19 Apr 2004, Mathihalli, Madhusudan wrote:
Since a lot of the async signals are blocked by default, I thought
it'll be good to provide a apr_(un)block_signal() api for those who want
to block/unblock only select signals. Here's a patch to do that.
Is this portable? (Admitting
On Wed, 17 Mar 2004, Sander Striker wrote:
1.20.2.3 +1 -1 apr-util/misc/apr_rmm.c
1.3.2.2 +10 -2 apr-util/test/testrmm.c
Sander and company - if the final tags of apr 0.9.5 / httpd 2.0.49 can
pick this up - it would be lovely. Well validated.
I'll make sure they get in
On Sun, 14 Mar 2004 [EMAIL PROTECTED] wrote:
This needs to get resolved. I believe the fix is to simply add the correct
checks to APR_STATUS_IS_TIMEUP, but I also would like to know if we really
need
to keep APR_STATUS_IS_ETIMEDOUT at all. Can we mark it deprecated?
+1 as far as I'm
I know it's got a few more patches I need to get in before it's ready to
go, but just so that I could go ahead and at least get started on this
(using some extended definition of tomorrow which technically ended
about 24 hrs ago, sigh)... I've tagged apr, apr-util, and apr-iconv as
On Mon, 15 Mar 2004, Geoffrey Young wrote:
if you could take a look at this
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25550
Noted, thanks!
On Sun, 14 Mar 2004, Guenter Knauf wrote:
For what is it good for that I'm familiar with CVS, have it on my
machine, and am able to contribute patches, if I'm not able to commit
them, and my posts get mostly ignored (as with many other posts too)
because either the commiters have no time for
On Sun, 14 Mar 2004, Cliff Woolley wrote:
I'll put my heads together with the PMC and see what we can come up
with.
Umm... just reread that... my heads... *crosses all (four? eight? ;)
eyes*... okay... I need a vacation ;)
On Fri, 12 Mar 2004, Craig Rodrigues wrote:
What's the status of apr 0.9.5? I'm getting many
requests to update apr in the FreeBSD ports system.
TR tomorrow.
I'll try to attend to any outstanding patches before I roll the RC.
--Cliff
I wanted to do this before I left for NY, but alas, time ran out. I'll
get back Wednesday night, so I'll do it then. If you want to get
something in before the TR, here's your chance. :) I'll also resurrect
the 1_0_BRANCH at that time, and then -dev will be 1.1-dev, hoping to get
1.0 out
On Sun, 29 Feb 2004 [EMAIL PROTECTED] wrote:
I've been lurking for the last few days, and this list is too quiet. :-) I'd
like to stir up trouble again, so I am officially asking to have my commit
access re-instated. I am in the middle of creating a new project that uses
APR,
and I would
On Tue, 24 Feb 2004, David Reid wrote:
+1 Can we make this a priority for the PMC Chair to persue with the
board?
I would, but the board (or rather Greg) is already on it. :)
Given that SVN is now 1.0 we should really get our asses in gear and get 1.0
out the door. Given the strong
On Mon, 23 Feb 2004, Scott Lamb wrote:
significant difference between them. In transferring either big or
small files with httpd-2.0 HEAD and ab over loopback on Darwin
(keepalive on). Which I'd think would be the ideal situation for seeing
an improvement...
Neither ab nor loopback make for
On Mon, 23 Feb 2004, Justin Erenkrantz wrote:
Well, if we believe the AL v2.0 is GPL-compatible, then this is a moot point,
I believe.
GPL-compatible means that Apache-licensed code can be added to a GPL
product and that that product can still be distributed under the GPL, not
the other way
On Tue, 24 Feb 2004, Sander Striker wrote:
This would make the use of any OS header files a derived work of the OS,
I can't imagine you think this is the case.
Not a good example; there's a specific exemption for that case IIRC.
--Cliff
On Mon, 12 Jan 2004, Craig Rodrigues wrote:
Has anyone made a move at releasing apr-0.9.5?
I have a lot of FreeBSD users asking me for an apr-0.9.5
release so that it can be added to the FreeBSD ports
tree.
Arhhh.. yet another thing on my list of things to do yesterday. :-/
I'll attempt
On Sun, 11 Jan 2004, Charles Bonello wrote:
I am a student studying business studies at school and I would like some
information about APR. Would you please forward some information.
Have you seen our website at http://apr.apache.org/ ? What additional
information would you like to know?
Where does it say that? httpd uses it extensively, so if it's not, I'd
tend to think we'd have noticed by now...
--Cliff
On Thu, 8 Jan 2004, Donald Doane wrote:
Okay, will do that, but it's called in
flood_easy_reports::easy_process_stats() and it seems APR
documentation implies it is not
On Thu, 8 Jan 2004, Donald Doane wrote:
The following comment is from apr_lib.h:
* apr_vformatter does not call out to any other code, it is entirely
* self-contained. This allows the callers to do things which are
* otherwise unsafe. For example, apr_psprintf uses the scratch
* space
On Thu, 8 Jan 2004, Sander Striker wrote:
Doable. Should be a fairly tiny patch to make this possible. It would
be a 'BEWARE! USE AT OWN RISK!' feature, since you are going to mess
Hah, like I said, Sander's the man. :-)
On Fri, 2 Jan 2004, Stas Bekman wrote:
Though I think it should be NUL-terminated, since NULL stands for a 0 pointer,
not '\0'.
ya ya ya ;)
:)
--Cliff
On Wed, 31 Dec 2003, Stas Bekman wrote:
- * @remark The buffer will be '\0'-terminated if any characters are stored.
+ * @remark The buffer will be '\\0'-terminated if any characters are
stored.
Can't this be worked around in some other way? People reading raw .h files may
get confused
On Thu, 18 Dec 2003, Bojan Smojver wrote:
You can put on the list of projects using APR my own mod_spin
(http://www.rexursive.com/software/modspin/). Not only does the module
use APR, but also the applications written for it use APR. Also, the API
that the module provides relies heavily on
On Wed, 17 Dec 2003, Brad Nicholes wrote:
incompatibilities in the bucket code. There are a number of places
where file lengths are defined as apr_size_t rather than apr_off_t.
What is the downside of redefining these variables as apr_off_t (ie.
off64_t rather than off_t)?
We went back and
On Wed, 17 Dec 2003, Brad Nicholes wrote:
before setting the content-length header. The problem is that there
appears to be only one bucket and the length of that bucket is
(actual_filesize - 4gig) for any file greater than 4gig.
Weird, but I can believe it.
Where should the dividing up of
On Wed, 17 Dec 2003, Brad Nicholes wrote:
Thanks. After doing some more digging I also ran across this chunk
of code myself. Casting the filesize to apr_size_t in the #else part of
the code was a dead give-away. I guess NetWare hit the odd combination
here in that we don't have
On Sat, 13 Dec 2003 [EMAIL PROTECTED] wrote:
bnicholes2003/12/13 12:32:49
Modified:include apr.hnw
Log:
large file support is causing problems with acrobat reader and PDF
files. Turning it off on NetWare until I can figure out why.
Acrobat Reader is just about the only
On Sun, 14 Dec 2003, [ISO-8859-15] André Malo wrote:
Acrobat Reader is just about the only client I know of that actually uses
byte range requests. So if PDF serving to acroread is broken, the
byterange filter is virtually always the culprit.
Nah, every download manager (e.g. wget) uses
On Tue, 9 Dec 2003, Jeff Trawick wrote:
+if (reslist-timeout) {
+if (apr_thread_cond_timedwait(reslist-avail,
+reslist-listlock, reslist-timeout) != APR_SUCCESS)
+apr_thread_mutex_unlock(reslist-listlock);
+return
On Tue, 9 Dec 2003, Mladen Turk wrote:
That was the bug.
if not returning whatever apr_thread_cond_timedwait()
returned, why not return APR_TIMEUP instead of APR_EAGAIN?
but like Cliff said I wonder why the retval of
apr_thread_cond_timewait() isn't appropriate?
The fixed patch uses
1 - 100 of 538 matches
Mail list logo
