To thoroughly confuse... On Tue, Apr 10, 2018 at 10:49 AM, Eric Covener <[email protected]> wrote: > On Tue, Apr 10, 2018 at 11:40 AM, William A Rowe Jr <[email protected]> > wrote: >> On Tue, Apr 10, 2018 at 7:41 AM, Steffen <[email protected]> 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 > AP_DECLARE? Pondering. 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.
