At 10:45 AM 11/29/2004, Justin Erenkrantz wrote: >--On Monday, November 29, 2004 10:48 AM +0100 Mladen Turk <[EMAIL PROTECTED]> >wrote: > >>Your patch breaks win32 build. >>The reason is that the AP_DECLARE is __stdcall while >>cmd_table is __cdecl. > >Huh? I don't know Win32 at all, so this makes no sense. > >>Can you revert the patch or use the AP_DECLARE_NONSTD >>or simple extern? > >It has to be AP_DECLARE to be buildable on Unix as the ap_listen.h functions >need to be in the exports.c hack - otherwise things don't work. -- justin
Unix should gather all AP_DECLARE, AP_DECLARE_NONSTD and AP_DECLARE_DATA sections. The difference for Win32 is that AP_DECLARE uses the 'standard' calling convention instead of the c flavor. This usually works and even speeds things up a bit, until we hit a function that takes variable arg lists. That's when things break down, the callee (function) can't pop the stack on return, because it can never be quite sure how much arg data the caller pushed onto the stack. That's when we use AP_DECLARE_NONSTD. In this case, registered hook functions are declared nonstd (the c flavor) because we aren't quite sure that users won't abuse one function in favor of another (e.g. have an extra arguement or two that the hooked function is unaware of.) Obviously it's also possible for a hook function to take var args and we didn't want to make a dozen oddball cases to cover these. The reason this popped up is that the function was not previously exported, therefore it was in the c convention as a local function. In the future, Mladen, please don't assume unix coders know this distinction and please go ahead, fix things up as necessary. Platform maintainers accept that folks will break code on their platform - it's a given. Bill
