To thoroughly confuse...

On Tue, Apr 10, 2018 at 10:49 AM, Eric Covener <> wrote:
> On Tue, Apr 10, 2018 at 11:40 AM, William A Rowe Jr <> 
> wrote:
>> On Tue, Apr 10, 2018 at 7:41 AM, Steffen <> wrote:
>>> Get:
>>> Error C2440 'function': cannot convert from 'int (__stdcall *)(conn_rec *)'
>>> to 'ap_HOOK_output_pending_t (__cdecl *)' libhttpd
>>> ..\VC15\trunk\server\core.c 5724
>> '(__stdcall *)(conn_rec *)' != '(__cdecl *) (conn_rec *)'
>> Callback entry points are generally declared AP_DECLARE_NONSTD
>> for this reason.
> It looks like the mod_ssl pattern is that it is not decorated at all.
> mod_ssl is the closest to this since it registers non-static functions
> from other C files.
> They are undecorated.

For any non-exported function, undecorated is NONSTD (just not
declared). For exported functions, AP_DECLARE "promotes" these
to the stdcall API (consistent with most languages default stack
args and retval manipulation (except C/C++/ASM). So one can read
AP_DECLARE_NONSTD as going right back to the same C/C++
mechanics, only with an exported entry point.

Those individual hook callbacks in ssl are static, and registered in
an initializer within the same source file.  In the declaration
static apr_status_t ssl_io_filter_output(ap_filter_t *f, ...
this would become
SSL_DECLARE_NONSTD(apr_status_t) ssl_io_filter_output(ap_filter_t *f, ...
to maintain the very same conventions as previous releases (now
with an exported symbol).

> ...But we already have this thing in util_filter with AP_DECLARE.
> Do we need to wrap it to effectively change to NONSTD or undecorated
> for what we register w/ ap_hook_* since it is already public as


Right now the stack unwinds would be ridiculous... would substitute
the AP_DECLARE with an AP_DECLARE_NONSTD() fn_nonstd()
flavor, and then have the originally named function invoke _nonstd().

But why is this an issue? grep -r output_pending in 2.4.x branch
in modules/... and server/... shows me nothing. No problem with
an MMN major change on 2.5 branch.

Reply via email to