[Python-Dev] Looking for a DL_xxPORT macro export (original) (raw)

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 DLxxPORT macros), DLEXPORT 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 .

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 .