[...] 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 Win32 unless we neglected to include the relevant declaration header when we hit the function's code. Since it didn't, that means MSVC had overridden our preference since our preference couldn't be honored. Unfortunately, as is their way, they never saw fit to _announce_ this with an emit. It has been _NONSTD() all this time.
The do processor fn's themselves must be exported with APR_DECLARE_NONSTD(),
and then _only_ if they need to be an exported entry point (e.g. 99% of the time
the process fn is simply a static fn in the source file that declares it.)
-APR_DECLARE_NONSTD(void) apr_table_do(int (*comp)(void *, const char *, const char *),
+APR_DECLARE_NONSTD(int) apr_table_do(int (*comp)(void *, const char *, const char *),
void *rec, const apr_table_t *t, ...);
Please create a new fn, and leave a fn apr_table_do() that simply invokes your
new apr_table_ fn, discarding the return code. You can notate apr_table_do as
deprecated in the next major release of apr (1.0) as we've done for the renames.
Please don't break binary compat in this way when we have no proper versioning in place just yet to track such a change.
In any case, I noticed this was odd when I looked at using the function once before (and this is the reason I never did.) Great thought, and following my suggestion above, +1!
Bill
