At 12:33 PM 8/14/2003, Cliff Woolley wrote:
>On Thu, 14 Aug 2003 [EMAIL PROTECTED] wrote:
>
>> > Sure... take a look at apr_os_file_get() which is declared in
>> > apr_portable.h
>>
>> This answer is, I'm surmising, unfortunately incomplete. That is, on
>> Unix systems, apr_os_file_get() will do t
My thought is that the existing code is resilient enough without any
cas logic; but I have been waiting for others to take the time to prove
that to themselves before we back down to simple inc/dec/assignment.
My other question - why is it necessary to explicitly use nested locks
within the pool c
At 07:28 PM 9/1/2003, Justin Erenkrantz wrote:
>> Brian Pane wrote:
>>
>> Here's my attempt at summarizing all the proposals.
>> There was a lot of debate about the naming of the time
>> type--whether it was good or bad to give it a name so
>> similar to time_t, whether the type name should reflect
At 02:37 PM 9/4/2003, Jeff Trawick wrote:
>comments?
++1 here.
>(hopefully you can cvs rm on the main branch and it still shows up in the 0.9
>branch :) )
Yes, it will show **deleted** on head, and remain on the branch, and can even
be committed to on the branch without ressurecting it to head.
At 01:28 PM 9/2/2003, Maarten Bekers wrote:
>To prevent an DoS, perhaps WaitForSingleObject() could be called in a loop
>with, check the value of GetOverLappedResult() for a 'sane' value (this can
>be the old MAX_SEGMENT_SIZE), and if the amount of bytes transmitted since
>the last call to GetOver
At 12:04 AM 9/3/2003, Stas Bekman wrote:
>Justin Erenkrantz wrote:
>>--On Tuesday, September 2, 2003 2:30 PM -0700 Stas Bekman <[EMAIL PROTECTED]>
>>wrote:
>>
>>>Other outstanding issues that IMHO can/should be fixed in 1.0.
>>>
>>>Configure issues:
>>>
>>>1) dealing with APR_HAS_LARGE_FILES on li
I noticed (and ment to comment right away) that you had branched
APR_0_9_BRANCH and APU_0_9_BRANCH on the apr-util module.
This commit illustrates why that won't work. I suggest we pick one
(and APU_0_9_BRANCH would be my preference) and remove the
other tag from the apr-util cvs module. It seem
At 11:23 AM 9/5/2003, Maarten Bekers wrote:
>> >To prevent an DoS, perhaps WaitForSingleObject() could be called in a
>loop
>> >with, check the value of GetOverLappedResult() for a 'sane' value (this
>can
>> >be the old MAX_SEGMENT_SIZE), and if the amount of bytes transmitted
>since
>> >the last
At 12:42 PM 8/8/2003, [EMAIL PROTECTED] wrote:
>Subversion users have been noticing some annoying behavior in our use
>of apr_filepath_merge() that only happens on Windows platforms. We
>call this function with the APR_FILEPATH_TRUENAME flag to get the case
>and segment delimiters all in shape. W
As a few here already know, we used the 'Standard' page size for our
apr-util SDBM implementation. This assures that you can modify our
sdbm files from perl and other tools.
However, it's pretty clear that 1024 just doesn't cut it when it comes
to huge objects from ssl caching and other sorts of
At 01:32 AM 9/19/2003, Mladen Turk wrote:
>I have a patch (send It back in April) that enable to use the atomic
>from C++ on WIN32.
>The problem is the fact that C++ distinguishes unsigned int and LONG
>mixage as an error.
That's our bug, then. Not redeclaring, but we need to make this consisten
At 03:38 PM 9/19/2003, William A. Rowe, Jr. wrote:
>At 01:32 AM 9/19/2003, Mladen Turk wrote:
>
>>I have a patch (send It back in April) that enable to use the atomic
>>from C++ on WIN32.
>>The problem is the fact that C++ distinguishes unsigned int and LONG
>>mixa
At 12:25 PM 9/22/2003, Brad Nicholes wrote:
> NetWare uses the Unix implementation of apr_file_dup() and
>apr_file_dup2(). There is not a NetWare specific implementation of
>these functions. After looking at the apr_file_t structures for Unix
>and NetWare, and comparing them to the initializatio
At 07:06 PM 9/24/2003, Blair Zajac wrote:
>Yes, I brought this up a month ago.
>
>See the thread with the subject
>
>"unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump"
>
>Sander responded there, but there's been no work on it yet.
I responded - prove that my changes no longer requir
Dumb Q perhaps; for APR-UTIL 1.0 don't we want to change:
typedef struct apr_bucket apr_bucket;
typedef struct apr_bucket_brigade apr_bucket_brigade_t;
etc
to follow our convention:
typedef struct apr_bucket_t apr_bucket_t;
typedef struct apr_bucket_brigade_t apr_bucket_brigade_t;
etc...
The no
At 01:55 PM 10/7/2003, Brian Pane wrote:
>William A. Rowe, Jr. wrote:
>
>>Dumb Q perhaps; for APR-UTIL 1.0 don't we want to change:
>>
>>typedef struct apr_bucket apr_bucket;
>>typedef struct apr_bucket_brigade apr_bucket_brigade_t;
>>etc
>>
Is apr_bucket_brigade_t a little wordy?
Perhaps apr_brigade_t says it all...
Bill
At 02:47 PM 10/7/2003, Cliff Woolley wrote:
>On Tue, 7 Oct 2003, William A. Rowe, Jr. wrote:
>
>> >>Dumb Q perhaps; for APR-UTIL 1.0 don't we want to change:
>> >>
>&g
At 05:48 PM 10/8/2003, Fisk, Kevin wrote:
>Is there any concept of reallocation to change the size of allocated memory
>inside a pool. If there is no data past the end of the allocated memory in
>the pool, it shouldn't require me to allocate a new buffer and transfer all of
>the data to the new
At 08:34 AM 10/15/2003, [EMAIL PROTECTED] wrote:
>trawick 2003/10/15 06:34:26
>
> Modified:include apr.h.in
> include/arch/unix apr_arch_networkio.h
> Log:
> need for SIOCATMARK on at least AIX and z/OS (OS/390 (MVS))
Thanks Jeff, knew it wouldn't be _that_ simple, but I
Including Jeff and Brian's efforts for their respective platforms, I'm
suggesting
the apr_socket_atmark() for backport to 0.9. Adjusted patch is attached.
configure.in rev 1.544 1.545
include/apr.h.in rev 1.128 1.129
include/apr.hnw rev 1.37
include/apr.hw rev 1.118
include/apr_network_io.h rev
I agree with all your suggestions and will return APR_ENOTIMPL if we find that
SOICATMARK is undefined in the 0_9 branch (with the appropriate comment.)
Anyone with other concerns? Otherwise I'll commit later tonight.
Bill
At 12:55 PM 10/16/2003, Jeff Trawick wrote:
>William A. Rowe, J
At 04:16 PM 10/16/2003, Norman Tuttle wrote:
>The conditions of lack of success for apr_socket_create() should include a
>case where memory wasn't available to allocate for the creation of the APR
>socket structure, but I did not see evidence of this in either the Win32 or
>Unix versions of the
At 05:13 PM 10/16/2003, [EMAIL PROTECTED] wrote:
>wrowe 2003/10/16 15:13:03
>
> Modified:.Tag: APR_0_9_BRANCH configure.in
> include Tag: APR_0_9_BRANCH apr.h.in apr.hnw apr.hw
>apr_network_io.h
> include/arch/unix Tag: APR_0_9
open call where I've hacked
in our default values, for anyone to experiment with.
Immediate beneficiaries include mod_ssl and dav, where pages may need
to be much larger than the default.
Bill
At 02:56 PM 9/19/2003, William A. Rowe, Jr. wrote:
>As a few here already know, we used the &#
At 08:07 AM 10/22/2003, Jim Jagielski wrote:
>++1 on concept and I'll be actually doing some
>testing soon.
>
>One problem is just that mod_ssl uses the default APR
>dbm which is the (non-optimal) sdbm. A cool fix would
>be to allow SSLSessionCache to pick out the underlying
>dbm implementation, si
I don't believe we need an _ex flavor if you are proposing this for APR 1.0.
Just change the args, the 1.0 version may break (expand) our api.
Bill
At 04:24 PM 10/23/2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
>Hi,
>I was wondering if there's any interest in having a option to m
I committed the fix and it builds here. What are your observations?
Bill
At 01:37 PM 10/30/2003, [EMAIL PROTECTED] wrote:
>Cliff Woolley wrote:
>
>>On Thu, 30 Oct 2003, Norman Tuttle wrote:
>>
>>
>>
>>>What is the latest stable build of the Apache APR, when was it produced,
>>>
>>>
>>
>>I
At 09:23 AM 11/7/2003, Jeff Trawick wrote:
>see patch... seems simple enough, but perhaps somebody knows some
>showstoppers that would prevent this from being implemented on some platform?
No, but the code's behavior is definitely not portable, and will make the user's
code very buggy...
>+APR_
At 10:39 AM 11/7/2003, Jeff Trawick wrote:
>William A. Rowe, Jr. wrote:
>
>>At 09:23 AM 11/7/2003, Jeff Trawick wrote:
>>
>>>see patch... seems simple enough, but perhaps somebody knows some
>>>showstoppers that would prevent this from being implemented on so
Ok, I can't quote chapter and verse when I'm not in my laboratory,
but I'm betting dollars to donuts that from configure.in
elif test "$ac_cv_sizeof_long_double" = "8"; then
int64_literal='#define APR_INT64_C(val) (val##LD)'
uint64_literal='#define APR_UINT64_C(val) (val##ULD)'
int64_t
At 03:00 PM 11/15/2003, Stas Bekman wrote:
>In apache 1.3 one could check whether a r->finfo is already opened by checking
>whether r->finfo.filehand is non-NULL. However with ap2/apr, r->finfo could be
>unitilialized and containing random garbage.
However, we could null out r->finfo.valid and r
-1 veto not vote. If we cannot support it, we cannot use it internally.
Bill
At 12:50 PM 11/17/2003, Aaron Bannert wrote:
>On Mon, Nov 17, 2003 at 06:11:06AM -0500, Joe Orton wrote:
>> On Sun, Nov 16, 2003 at 06:25:00PM -, Jeff Trawick wrote:
>> > trawick 2003/11/16 10:25:00
>> >
>> >
At 03:29 PM 11/17/2003, William A. Rowe, Jr. wrote:
>-1 veto not vote. If we cannot support it, we cannot use it internally.
I want to make sure folks understand what my objection is;
if we drop NESTED v.s. UNNESTED I'm fine with that.
Moving the choice to a private header so we ca
It looks ok, but I think my objection was that everything else in finfo is
authoritative. This field might be mis-capitalized (on case-insensitive
platforms), unrooted, or whatever.
Patch committed, but I think we need to call this out in documentation.
Bill
At 12:44 PM 11/18/2003, Geoffrey You
At 04:44 PM 11/19/2003, Geoffrey Young wrote:
>William A. Rowe, Jr. wrote:
>>It looks ok, but I think my objection was that everything else in finfo is
>>authoritative. This field might be mis-capitalized (on case-insensitive
>>platforms), unrooted, or whatever.
>>Patc
We need to axe or decorate the symbol NO_USE_SIGACTION in our
ongoing effort to prevent namespace clashes.
However, this turned out to be a nontrival problem. It doesn't appear
that this option was ever a tunable APR option.
We do have a flag APR_HAVE_SIGACTION which is tested and
configured for
At 09:00 PM 11/20/2003, Jeff Trawick wrote:
>William A. Rowe, Jr. wrote:
>
>>We need to axe or decorate the symbol NO_USE_SIGACTION in our
>>ongoing effort to prevent namespace clashes.
>
>sounds good
>
>>We do have a flag APR_HAVE_SIGACTION which is tested and
&
At 03:29 PM 11/21/2003, Sander Temme wrote:
>> You may have less grief (if you are checking out from CVS) to continue
>> to checkout from the tag APR_0_9_BRANCH (and the corresponding tag
>> APU_0_9_BRANCH on apr-util).
>
>I am not sure, and Sander Striker last weekend was not sure, what is
>actual
At 07:54 PM 11/21/2003, Brian Havard wrote:
>> Brian - can you make sure the OS/2 code is OK?
>
>yeah, it works, but it would have been better to resurrect poll.c rather
>than lump apr_poll() in with pollset.c.
I concur, since Win32 will have a replacement for apr_poll once I work out
where the t
At 09:23 AM 12/4/2003, [EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>
>>fwiw, I'm using gcc -O2 to get the inline attribute to kick in.
>>Regardless of what we do with the API, we should commit the inline attribute
>>IMO because it is a nearly free performance boost.
>
>ummm, scratch that
Because the old value isn't atomically fetched with the add/sub operation,
is this solution worse than no solution at all?
Perhaps we need two flavors, one fast (add/sub) that do *not* rely on any
result value (returning void) and another that explicitly returns the old value
on add, and the new
annert wrote:
>On Thu, Dec 11, 2003 at 01:50:46PM -0600, William A. Rowe, Jr. wrote:
>> But the 2.0 architecture is entirely different. We need a poll but it's not
>> entirely
>> obvious where to put one...
>>
>> One suggestion raised in a poll bucket: when
Red flag,
this means you break binary compatibility and we had better call that out
somehow, if this code is tagged and released before the solution is found.
Bill
At 02:32 PM 12/13/2003, [EMAIL PROTECTED] wrote:
>bnicholes2003/12/13 12:32:49
>
> Modified:include apr.hnw
> Log:
> lar
At 11:30 AM 12/17/2003, Brad Nicholes wrote:
> Buckets being restricted to a size_t is kind of what I expected. So
>here is what I am seeing and maybe you can help me work through this.
>In ap_content_length_filter() the code attempts to add up all the
>lengths of all of the buckets and put th
At 02:31 PM 1/8/2004, Jim Jagielski wrote:
>We're being sloppy with these... Shouldn't all FNM_* in
>httpd be using the APR versions? Just grepping for
>FNM_PERIOD...
I would think so ... patch on :)
>./modules/generators/mod_autoindex.c:
>FNM_NOESCAPE | FNM_PERIOD
The question was due to a typo in a hastily written description;
At 08:55 PM 1/8/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
> * othe
At 04:51 PM 1/13/2004, Günter Knauf wrote:
>do you still expect massive changes with APR 1.0 ?
I have the sense that folks want to see:
* platform neutral apr_poll() that works on apr_file_t's as well, since so many
daemons and other applications will require this. Non trivial - but we may
At 07:05 PM 1/13/2004, Brad Nicholes wrote:
>I don't think so because the "split into multiple bucket" code was
>only enabled if both large_file and send_file was enabled. Which meant
>that on a non-large_file build the check for ENABLE_SENDFILE_OFF wasn't
>there anyway. If they have large_fi
What ship? Did 2.1.0 actually go anywhere? Seems from the folks complaining
that they didn't feel we ever released it.
Proof is in the pudding - are we at 2.1.1-dev?
Bill
At 01:54 AM 1/16/2004, you wrote:
>--On Tuesday, January 13, 2004 5:28 PM -0600 "William A. Rowe, Jr." &
At 08:41 AM 1/16/2004, Günter Knauf wrote:
>Hi,
>> What ship? Did 2.1.0 actually go anywhere? Seems from the folks
>> complaining that they didn't feel we ever released it.
>correct - but I believe Justin meant APR 1.0 and not httpd...
>and with APR I've the same feeling than he:
>all those doing
At 04:01 PM 1/16/2004, Günter Knauf wrote:
>> ... should we modify the installed library name libapr-1.so to designate
>> that the
>> user is running a dev (non-release) version when using an arbitrary CVS
>> checkout? Something like libapr-dev-1.so?
>I really appreciate that you want to take care
At 01:33 PM 2/10/2004, Lev Serebryakov wrote:
>Hello, dev! How are you?
>
>amd64-freebsd:
>
>configure: WARNING: you should use --build, --host, --target
>checking build system type... Invalid configuration
>`amd64-portbld-freebsd5.2': machine `amd64-portbld' not recognized
>configure: error: /bin
Unless someone speaks up in the next 60 minutes, I plan to splat the
new license upon apr/apr-util/apr-iconv repositories.
Speak now if you are already dug into it.
Bill
At 03:31 AM 2/17/2004, Ben Reser wrote:
>On Wed, Feb 04, 2004 at 03:22:17PM +, Joe Orton wrote:
>> On Mon, Feb 02, 2004 at 05:19:09PM -0800, Ben Reser wrote:
>> > On Wed, Jan 28, 2004 at 04:45:26PM -0800, Ben Reser wrote:
>> > > So I guess I'll look into redoing it to use int, long or long long
At 12:48 PM 2/18/2004, Ben Reser wrote:
>On Tue, Feb 17, 2004 at 01:15:12PM -0600, William A. Rowe, Jr. wrote:
>> I am against changing the default size or alignment of any data type
>> in
>> APR_0_9_BRANCH. If this [has] happened we break all binary compat.
>
>Umm
At 01:33 PM 2/23/2004, Scott Lamb wrote:
>On some older versions of platforms (Linux 2.2), these #defines exist but do
>not work - it's not possible to set them. Can I assume that if APR is built
>with a kernel in which it does work (Linux 2.4), it will be run with one as
>well? Or should I inc
At 11:00 AM 2/26/2004, David Reid wrote:
>Just did a totally clean checkout on beos to try and get things building
>again, and the buildconf script worked almost as advertised - but managed to
>miss out the entire file_io/unix directory!
>
>I suspect because there is an empty file_io/beos directory
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? Can an arbitrary value, e.g. 128k,
have any relationship b
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
>> ===
At 08:01 PM 3/1/2004, Jeff Trawick wrote:
>William A. Rowe, Jr. wrote:
>>At 04:14 PM 3/1/2004, Jeff Trawick wrote:
>>>[EMAIL PROTECTED] wrote:
>>>>
>>>> (*new)->pool = pool;
>>>>+(*new)->detach = 0;
>>>
>>>btw
At 02:15 AM 3/14/2004, Robert Norris wrote:
>Attached is a patch that adds a function apr_pollset_update(). This
>updates the list of requested events for the descriptor in the
>underlying implementation for a descriptor that is already in a pollset.
>...
>The optimisation that I'd like to do is to
>rbb 2004/03/15 10:33:30
>
> 1.1 apr/test/globalmutexchild.c
>...
> int main(int argc, const char * const argv[])
> {
> apr_pool_t *p;
> int i = 0;
> apr_global_mutex_t *global_lock;
>
> apr_initialize();
> atexit(apr_terminate);
>
>
At 12:56 PM 3/15/2004, [EMAIL PROTECTED] wrote:
>Quoting "William A. Rowe, Jr." <[EMAIL PROTECTED]>:
>
>>
>> >rbb 2004/03/15 10:33:30
>> >
>> > 1.1 apr/test/globalmutexchild.c
>> >...
>> > int
At 12:50 PM 3/16/2004, you wrote:
>[EMAIL PROTECTED] wrote:
>> wrowe 2004/03/16 10:17:33
>>
>> Modified:misc apr_rmm.c
>>test testrmm.c
>> Log:
>> Fix a signed/unsigned mismatch that caused an underflow.
>>
>> Patch by Ahab A.
>> Test by Phillip M C
At 12:07 PM 3/17/2004, Philippe M. Chiasson wrote:
>On Tue, 2004-03-16 at 17:53 -0500, Geoffrey Young wrote:
>> >
>> > Care to +1 for backport & I'll make it so today?
>>
>> well, I'm not sure that my involvement in apr warrants a vote, but I'm +1 in
>> any case :)
>
>Same argument from me here,
How is this apr? seems you have a pool scope bug causing a double-clear?
Bill
At 12:08 PM 3/19/2004, Mathihalli, Madhusudan wrote:
>Hi,
>I am trying to test a SSL Proxy server using sslswamp, and I'm running
> into the following segmentation fault !
>
>There appears to be some missing e
At 06:03 PM 3/25/2004, Joe Orton wrote:
>On Thu, Mar 25, 2004 at 03:49:09PM -0800, Stas Bekman wrote:
>>
>> That's a bad idea, IMHO, because ARP_HAS_LARGE_FILES will still report
>> false. You suggest to create a mess, where the library will report one
>> thing but behave as another.
>
>I was th
"Based on the new definitions, the SI prefixes, k, M, and G, are back to their
original meaning of 1,000, 1,000,000, and 1,000,000,000, respectively. The
commonly known binary prefixes are written as Ki, Mi, and Gi and pronounced as
kibi, mebi, and gibi, respectively."
I believe that is 2^10, s
At 05:28 AM 3/26/2004, Joe Orton wrote:
>On Thu, Mar 25, 2004 at 04:44:02PM -0800, Stas Bekman wrote:
>> I expect a true value of APR_HAS_LARGE_FILES to mean "-D_LARGEFILE_SOURCE
>> -D_FILE_OFFSET_BITS=64" on linux, and whatever are the equivalents are on
>> other platforms (are they different or
At 02:51 PM 3/26/2004, Carl Edwards wrote:
>In that case shouldn't it be 'Ki'?
Of course but the size expectations for the returned text have always
been one character for the únit. Shall we make this change to 1.0 and
let folks catch up? (And drop if needed)
At 06:49 AM 3/29/2004, Jeff Trawick wrote:
>Ben Laurie wrote:
>>Jeff Trawick wrote:
>
>>>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 don't consider it broken?
>
>a
If the platform resolves to win32 (building subset/win32/*.c) then we
just need to trick it - win 32 has its own hardcode cases.
Bill
At 09:16 PM 3/29/2004, Greg Matheson wrote:
>Has anyone built on MinGW? I want to use Subversion with
>perl so I need the SWIG bindings and this requires building
At 11:42 AM 4/9/2004, you wrote:
>I am trying to build the apr under win32 with no luck. All of the
>downloads from the mirror sits I have gotten have had corrupted .dsp
>files. How can I get good copies that work?
look at apr/build/lineends.pl, invoke it from the apr (& apr-util) root
and it wi
Sorry, that is a later SDK header than you have. However I've committed
a similar hack to Microsoft's for 32 bit cpu's.
Please cvs up - recompile - and report back.
Also eliminated the unary negation applied to unsigned value warning
(a side effect of using add 2s compliment value of an unsigned
At 12:36 AM 3/15/2004, Cliff Woolley wrote:
>Let me know if you have specific things you want to see in 0.9.5 (that are
>doable in say a day's time... nothing more than that).
Ok, after playing in an entirely-seperate build of apr, apr-util, and finally
httpd, I came across something that disturb
At 01:36 PM 4/16/2004, André Malo wrote:
>* André Malo <[EMAIL PROTECTED]> wrote:
>
>> Aloa,
>>
>> APR should support those POSIX bits on systems where it makes sense.
>> Attached is a patch for file_io/unix, which seems to used for netware and
>> OS/2 as well (but seems to be ok in the first glan
At 01:52 AM 4/19/2004, makl wrote:
>The only drawback I have found is that wmain (misc/win32/apr_app.c),
>apr_wastrtoastr (misc/win32/internal.c) and warrsztoastr
>(misc/win32/start.c) are not useable since they use functions from the
>MS debugging library.
Those debugging mallocs are only presen
At 11:00 AM 4/22/2004, Ed Holyat wrote:
>I was wondering if any of these problems were being addressed?
Ed, all of us are capable of (and several of us do) building and running
the test suite, so the problems are not unknown.
Your analysis of the compare_uid logic was excellent and should
spawn
At 10:33 AM 4/22/2004, you wrote:
>very well then (I'll change APR_SUCCESS to APR_ENOTIMPL) - is it the same for
>win32 also ?
Did you add a no-op for that platform that *affects* the expected
behavior or an application? Then yes - of course it must return
APR_ENOTIMPL.
You can @bug the doxygen
At 03:05 AM 5/1/2004, makl wrote:
>The build was tested with the following components:
Thank you for the toolkit links, assembling that toolchain for testing...
>* misc/win32/internal.c
> Commented out due to issues with _malloc_dbg.
That's the wrong solution - I already explained on an earlie
At 08:02 PM 5/21/2004, Stas Bekman wrote:
>Before apr 1.0 is cast in stone any chance public enums and defines will get
>sensible names?
>It all looks nice in the declaration but in the code, one needs to scratch the
>head to figure out what APR_REG means. Why not have /^APR_FILETYPE_/ prefix?
>
At 03:50 PM 5/23/2004, André Malo wrote:
>Hi,
>
>/* MSVC 7.0 introduced _strtoui64 */
>#if _MSC_VER >= 1300 && _INTEGRAL_MAX_BITS >= 64
>#define APR_HAVE_INT64_STRFN 1
>#define APR_INT64_STRFN _strtoui64
>...
>
>This should be _strtoi64, because apr_int64_t is signed.
IIRC, in that compiler
At 09:05 PM 5/26/2004, Stas Bekman wrote:
>I've posted the following wording:
>
>/**
> * Validate hashes created by APR-supported algorithms: md5 and base64.
> * hashes created by crypt are supported only on platforms that provide
> * crypt(3), so don't rely on that function unless you know that y
At 04:50 PM 5/26/2004, André Malo wrote:
>* André Malo <[EMAIL PROTECTED]> wrote:
>> * "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
>> > At 03:50 PM 5/23/2004, André Malo wrote:
>> > >
>> > >/* MSVC 7.0 introduced _str
At 07:34 AM 5/27/2004, Geoffrey Young wrote:
>> I beg your pardon, gentlemen. Would you be so kind to decide first
>> between yourself whether this is a bug or not? According to Ryan it's
>> not a bug, according to your comment above, Bill, it is.
>
>while I've been up most of the night, so I migh
At 07:44 AM 5/28/2004, Bill Stoddard wrote:
>Failure scenario:
>default_handler opens a pdf file to be sent via apr_sendfile (in other words,
>the file is opened for overlapped i/o aka APR_XTHREAD).
>[snip]
Doh! Thank you Bill for nailing down what's happened, here.
>A secondary issue I'd like
At 11:55 AM 5/28/2004, Bill Stoddard wrote:
>>Read the comment above. APR_XTHREAD can apply any time we need
>>to share the same file across multiple threads. DuplicateHandle(), for
>>an overlapped open, actually points at the same file. The only risk here
>>is that if you make this change, you
At 08:28 PM 6/3/2004, Justin Erenkrantz wrote:
>On Thu, Jun 03, 2004 at 06:16:06PM -0700, Greg Stein wrote:
>> Because it has been empirically proven that "wait for X" does not work.
>> Without a change in point-of-view, we'll never get it released. Thus, the
>> "just ship the frickin' thing" is a
At 04:31 AM 6/4/2004, Justin Erenkrantz wrote:
>I took a look at the locking problem, and I think it can be fixed rather
>trivially. This is a minor problem in that it only affects the case where the
>child doesn't share memory addresses - such as when happens by using
>apr_proc_create. Hence, a
Joe,
so you are suggesting since it's broke on Unix (but works on Win32
and possibly elsewhere), that nested|default|unnested will go away?
In the meantime "The test suite is passing on most of the Unixes",
and "People have lived with this 'broken' API forever" seem to be the
only justificat
At 03:33 PM 6/4/2004, Stas Bekman wrote:
>Thanks Noah, but this is exactly why I didn't do that and asked here first.
>It's not about just changing the API, since you will break any application
>that relies on that. You must provide backwards compatibility which should be
>deprecated and will b
'm talking about:
>
>Subject: Re: enum and defines naming
>
>William A. Rowe, Jr. wrote:
>> At 08:02 PM 5/21/2004, Stas Bekman wrote:
>>
>>> Before apr 1.0 is cast in stone any chance public enums and defines will
>>> get sensible names? It all looks nice
At 07:42 AM 6/4/2004, Joe Orton wrote:
>On Fri, Jun 04, 2004 at 02:31:48AM -0700, Justin Erenkrantz wrote:
>> I took a look at the locking problem, and I think it can be fixed
>> rather trivially. This is a minor problem in that it only affects the
>> case where the child doesn't share memory addr
>clar2004/06/11 13:13:19
>
> Added NetWare specific option in apr_cmdtype_e to start program in a
> separate address space for cmdtype field in apr_procattr_t struct
>
> --- apr_thread_proc.h 10 Jun 2004 10:57:24 - 1.105
> +++ apr_thread_proc.h 11 Jun 2004 20:13:19 -
At 08:45 PM 6/12/2004, [EMAIL PROTECTED] wrote:
>OK, here is the proc mutex re-org. This is ugly, but it passes all of the
>tests, using both fork and proc_create. The only problem with this patch,
>is that it doesn't do the configure magic to actually setup FORK_DEFAULT
>and PROC_CREATE_DEFAULT
At 07:35 AM 6/8/2004, [EMAIL PROTECTED] wrote:
>On Tue, 8 Jun 2004 [EMAIL PROTECTED] wrote:
>> On Mon, 7 Jun 2004, William A. Rowe, Jr. wrote:
>>> > At 07:42 AM 6/4/2004, Joe Orton wrote:
>> > >On Fri, Jun 04, 2004 at 02:31:48AM -0700, Justin Erenkrantz wrote:
>
At 04:50 AM 6/15/2004, Justin Erenkrantz wrote:
>--On Monday, June 14, 2004 5:15 PM +0100 David Reid <[EMAIL PROTECTED]> wrote:
>
>>- we need to decide if Ryan's proposed fix to the mutex_child_init should
>>stay or we stick with existing api. I've not been involved in it heavily,
>>BUT can we have
At 06:24 PM 6/15/2004, David Reid wrote:
>Just to keep people up to date with progress :-)
>
>Ben's point about the md5 code is well made and so rather than change the
>api I think we should fix/review the code to try and make the return values
>more meaningful.
Agreed here.
>Nick Kew's patch for
At 10:42 AM 6/22/2004, David Reid wrote:
>> jfclere 2004/06/22 03:42:23
>>
>> Modified:include apr_xml.h
>>xml apr_xml.c
>> Log:
>> Arrange the code to get it running on EBCDIC machines.
>> Add 2 conversions routines to convert the document tree in the machine
At 01:34 PM 6/22/2004, Graham Leggett wrote:
>Hi all,
>
>If APR is to finally stand on it's own, would anyone object to an inclusion of
>an RPM spec file in v1.0.0?
I wouldn't mind an rpm spec file for 0.9.6 either. +1
Bill
701 - 800 of 3471 matches
Mail list logo
