[Python-Dev] Looking for a DL_xxPORT macro export

Tim Peters tim_one@email.msn.com
Sat, 26 Aug 2000 04:14:48 -0400


[Tim, gripes about someone putting module init function names in
 both DL_IMPORT and DL_EXPORT macros]

[Fred Drake]
> That was me.

My IRC chat buddy Fred?  Well, can't get mad at *you*!

>> On Windows, that yields the result I (naively?) expected:
>> compiler warnings about inconsistent linkage declarations.

> Ouch.

Despite that-- as MarkH said later --these macros are as damnably confusing
as original sin, that one says "IMPORT" and the other "EXPORT" *may* have
been cause to guess they might not play well together when applied to a
single name.

> ...
>   Compiling with gcc using the -Wmissing-prototypes option causes a
> warning to be printed if there isn't a prototype at all:

Understood, and your goal is laudable.  I have a question, though:  *all*
module init functions use DL_EXPORT today, and just a few days ago *none* of
them used DL_IMPORT inside the file too.  So how come gcc only warned about
two modules?  Or does it actually warn about all of them, and you snuck this
change into pyexpat and parsermodule while primarily doing other things to
them?

> I can either change these to "normal" prototypes (no DL_xxPORT macros),
> DL_EXPORT prototypes,

I already checked that one in.

> or remove the prototypes completely, and we'll just have to ignore
> the warning.

No way.  "No warnings" is non-negotiable with me -- but since I no longer
get any warnings, I can pretend not to know that you get them under gcc
<wink>.

>   If you can write a few sentences explaining each of these macros and
> when they should be used, I'll make sure they land in the
> documentation.  ;)

I can't -- that's why I posted for help.  The design is currently
incomprehensible; e.g., from the PC config.h:

#ifdef USE_DL_IMPORT
#define DL_IMPORT(RTYPE) __declspec(dllimport) RTYPE
#endif
#ifdef USE_DL_EXPORT
#define DL_IMPORT(RTYPE) __declspec(dllexport) RTYPE
#define DL_EXPORT(RTYPE) __declspec(dllexport) RTYPE
#endif

So if you say "use import", the import macro does set up an import, but the
export macro is left undefined (turns out it's later set to an identity
expansion in Python.h, in that case).  But if you say "use export", both
import(!) and export macros are set up to do an export.  It's apparently
illegal to say "use both", but that has to be deduced from the compiler
error that *would* result from redefining the import macro in an
incompatible way.  And if you say neither, the trail snakes back to an
earlier blob of code, where "use import" is magically defined whenever "use
export" *isn't* -- but only if MS_NO_COREDLL is *not* defined.  And the test
of MS_NO_COREDLL is immediately preceded by the comment

    ... MS_NO_COREDLL (do not test this macro)

That covered one of the (I think) four sections in the now 750-line PC
config file that defines these things.  By the time I look at another config
file, my brain is gone.

MarkH is right:  we have to figure what these things are actually trying to
*accomplish*, then gut the code and spell whatever that is in a clear way.
Or, failing that, at least a documented way <wink>.