apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr_table_do
Date Fri, 28 Jun 2002 13:16:12 GMT
At 02:13 AM 6/28/2002, Cliff Woolley wrote:
>[...]
>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



Mime
View raw message