Jeff Trawick [EMAIL PROTECTED] writes:
The header file defines in apr_private.h are busted and APR won't
build. Here is a glaring example:
Summary of ths solution:
We picked up a bad sed from 4.6-STABLE, which broke this. We then
picked up a subsequent fix, and we build again on daedalus*.
From: [EMAIL PROTECTED]
Sent: 28 June 2002 13:53
Jeff Trawick [EMAIL PROTECTED] writes:
The header file defines in apr_private.h are busted and APR won't
build. Here is a glaring example:
Summary of ths solution:
We picked up a bad sed from 4.6-STABLE, which broke this. We then
At 02:13 AM 6/28/2002, Cliff Woolley wrote:
[...]
First, why is apr_table_do APR_DECLARE_NONSTD()'d in the header file, but
APR_DECLARE()'d in the .c file? I'm guessing the _NONSTD() is the right
one, but I'm still a bit hazy on these things.
That is a bug, AFAICT. It should be picked up by
Sander Striker [EMAIL PROTECTED] writes:
*slight complication... during this sed trauma, autoconf 2.53 became
the default autoconf on daedalus, and it doesn't get along well with
APR;
Is that *BSD specific? ac2.53 works fine for me on linux with APR.
perhaps...
The first fun comes
I have one bit that must be broken before 1.0, and cannot be remedied easily.
I'd like to simply break these things before Apache 2.0.40 is tagged.
apr_pstrcatv should have never been declared _NONSTD, it was and there
isn't much we can do about it without breaking binary compat or introducing
a
On 28 Jun 2002, Jeff Trawick wrote:
The first fun comes during buildconf processing:
$ ./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.53 (ok)
buildconf: libtool version 1.3.4 (ok)
Copying libtool helper files ...
Creating include/arch/unix/apr_private.h.in
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
I have one bit that must be broken before 1.0, and cannot be remedied easily.
I'd like to simply break these things before Apache 2.0.40 is tagged.
+1 on all counts. 2.0.40 will already require a full recompile anyway.
Other users of APR must
William A. Rowe, Jr. wrote:
At 02:13 AM 6/28/2002, Cliff Woolley wrote:
[...]
First, why is apr_table_do APR_DECLARE_NONSTD()'d in the header file, but
APR_DECLARE()'d in the .c file? I'm guessing the _NONSTD() is the right
one, but I'm still a bit hazy on these things.
That is a bug, AFAICT.
...since Friday, 28-Jun-2002 10:43:24 PDT. This build is basically 2.0.39 with
a patch to apr_sendfile to deal with a change to the FreeBSD sendfile() API. We
had 88 sendfile_it_all asserts pop today, so I decided to put the new build into
production even though there was a fair amount of
At 01:22 PM 6/28/2002, you wrote:
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
If Cliff wants to commit the semantic change to apr_table_[v]do, I'll
+1 here and raise you a _NONSTD correction. Along with Sander's
changes to make the unsafe transparent apr_allocator.h structure
opaque, I'd
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
IMHO, the implementation is what people have tested, not the documented
behavior. Use the source, luke :-)
But what I'm saying is that I don't think anybody *has* tested it. I
couldn't find a single use case in Apache where the called function
I want to break something: binary compatibility for the pool API.
This has been on my list for a long time, but I haven't yet had
time to implement it.
What I'm thinking of is the following:
* Preface the apr_pool_t structure with a set of function
pointers for the pool's methods: alloc, free,
On Fri, 28 Jun 2002, Justin Erenkrantz wrote:
Sounds like SMS. We could never overcome speed limitations and we
always seemed to place blame on the function pointers as the reason
why the SMS performance wasn't as good as pools.
We had function pointers *and* wrapper functions. We never
If it is used by -anybody- they trust the existing implementation.
That said, it should behave sensibly. The fact that you've asked three
times says you want to change it.
Make it so ;-)
Bill
At 01:38 PM 6/28/2002, Cliff Woolley wrote:
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
IMHO, the
On Fri, Jun 28, 2002 at 12:11:09PM -0700, Brian Pane wrote:
I want to break something: binary compatibility for the pool API.
This has been on my list for a long time, but I haven't yet had
time to implement it.
What I'm thinking of is the following:
* Preface the apr_pool_t
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
If it is used by -anybody- they trust the existing implementation.
That said, it should behave sensibly. The fact that you've asked three
times says you want to change it.
Hehehehe You noticed? :) Sorry to be a pest, I'm just getting sick of
Since we're talking about semantics, breakage, etc, I'll take the
opportunity to bore everybody with an issue I'd like resolved, too;
Namely, the semantics of the APR_STATUS_IS_* macros.
I've said several times before that APR_STATUS_IS_ENOENT and
APR_STATUS_IS_ENOTDIR don't have the same
At 02:43 PM 6/28/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
Since we're talking about semantics, breakage, etc, I'll take the
opportunity to bore everybody with an issue I'd like resolved, too;
Namely, the semantics of the APR_STATUS_IS_* macros.
I've said several times before that
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
What I'd like to propose is that we document that, for any given status
code, _more_ than one APR_STATUS_IS* macro can match, and it's the
programmer's responsibility to decide in what order to make the tests.
+1
--Cliff
At 02:11 PM 6/28/2002, Brian Pane wrote:
I want to break something: binary compatibility for the pool API.
This has been on my list for a long time, but I haven't yet had
time to implement it.
What you are describing is [was] SMS.
Even with the opaque structure, we are still facing derefs that
Justin Erenkrantz wrote:
On Fri, Jun 28, 2002 at 12:11:09PM -0700, Brian Pane wrote:
I want to break something: binary compatibility for the pool API.
This has been on my list for a long time, but I haven't yet had
time to implement it.
What I'm thinking of is the following:
* Preface the
On Fri, Jun 28, 2002 at 12:22:01PM -0700, Brian Pane wrote:
I think SMS's use of a wrapper function to do the indirect method
call was the main problem, which is why we'd have to use a macro
instead if we reintroduced a function pointer model.
Count me confused, but what is the difference
On Fri, 28 Jun 2002, Justin Erenkrantz wrote:
p-alloc
and
#define apr_palloc(...) p-alloc
None, but that's not what we were doing with SMS.
to the fact that we used to have a function like this:
apr_palloc()
{
return p-alloc();
}
Yeah, but it did even more. It was more like:
23 matches
Mail list logo
