At 04:13 PM 01/21/2002, William Rowe wrote:
>The following (decorated, default) exported symbol names, and the
>attached
>asm output from footest and footest2 illustrate that _stdcall is
>ignored
>for vararg prototypes :)
looking up __stdcall in the MSVC help gives this:
The __stdcall calling c
From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Monday, January 21, 2002 9:44 AM
> Upon closer inspection, ap_rprintf() has been NON_STD for ages, so it's fine as is.
>Not
> sure why it showed up on Rowe-san's list :-o
It went to _NONSTD in 1.302, and back to std in 1.309.
The tricky bit - i
Upon closer inspection, ap_rprintf() has been NON_STD for ages, so it's fine as is. Not
sure why it showed up on Rowe-san's list :-o
Bill
- Original Message -
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 21
Looks like ap_rprintf is still broken (or fixed in a way that is binary incompatable
:-)
I'll fix this now...
Bill
> No, the original code was, simply, broken. We must find a way to break
> compatibility for modules using _those_few_functions_, alone. They are;
>
> ap_snprintf
ap.h - Ok
> ap
On Fri, Jan 18, 2002 at 12:53:33PM -0500, Bill Stoddard wrote:
> >
> > > I think we concluded that e would rather not break binary compatability on
>Windows or
> any
> > > other platform. So the part of the patch commited on 12/28/01 12:03 AM that
>breaks
> > > compatability needs to be removed
At 12:53 PM 01/18/2002, Bill Stoddard wrote:
>If we break binary compatability with even one function, we need to
>bump the MMN major.
That wouldn't do anything, because a module using one of these
functions will never get a chance to check the MMN. The Windows
loader will prevent it from loa
I tend to agree with Bill Stoddard's POV... I think the way they had been
exported were "OK" only because of the lack of reported problems. So that
needs to be addressed.
There is also the mod_proxy stuff being massaged in from Chuck.
There's also one outstanding Cygwin patch which I'm waiting f
>
> > I think we concluded that e would rather not break binary compatability on Windows
>or
any
> > other platform. So the part of the patch commited on 12/28/01 12:03 AM that breaks
> > compatability needs to be removed or reworked.
>
> No, the original code was, simply, broken. We must find a
From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Friday, January 18, 2002 10:37 AM
> > Two outstanding issues remain I believe...
> >
> > 1. Chuck integrating the HTTP/1.c compliant mod_
>
> That would be HTTP/1.1... where did that 'c' come from? :-)
Was wondering which newly published RFC I m
From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Friday, January 18, 2002 10:32 AM
> I think we concluded that e would rather not break binary compatability on Windows
>or any
> other platform. So the part of the patch commited on 12/28/01 12:03 AM that breaks
> compatability needs to be removed
> Two outstanding issues remain I believe...
>
> 1. Chuck integrating the HTTP/1.c compliant mod_
That would be HTTP/1.1... where did that 'c' come from? :-)
Bill
to be removed or reworked.
Anything else? I would like to tag Sunday night.
Thanks,
Bill
- Original Message -
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 15, 2002 12:14 PM
Subject: Tag 1.3.23?
> I am reasonable sure
> From: "Thomas Eibner" <[EMAIL PROTECTED]>
> Sent: Wednesday, January 16, 2002 10:48 AM
>
>
> > On Tue, Jan 15, 2002 at 12:14:09PM -0500, Bill Stoddard wrote:
> >
> > Does the CHANGES file need to include something about this:
> >
> > from ApacheCore.def:
> > revision 1.29
> > date: 2001/12/
13 matches
Mail list logo
