On Mon, 10 Oct 2022, Pali Rohár wrote:
On Monday 10 October 2022 14:25:07 Martin Storsjö wrote:
But when building code within mingw-w64-crt, _CRTIMP expands to nothing. I
guess this is generally desireable when implementing some of the functions
that are marked _CRTIMP (we generally shouldn't have a dllimport declaration
of the function visible when we're implementing it).
Hm... if mingw-w64 runtime wants to redefine some function then it needs
to statically link redefined function into the final executable, right?
So should not in this case completely omit _CRTIMP to ensure that
function does not have dllimport to prevent useless usage of _imp_
pointer wrapper?
Yes, one can do that too. The __imp_ pointer wrappers are mostly used for
things which are dllimport in one CRT version but not in another. I guess
it kinda depends from case to case, what's the most correct/neat way of
handling it.
I think the common pattern within mingw-w64-headers is to simply use the
first form via the explicit __MINGW_IMP_SYMBOL redirection for any data
symbols, while _CRTIMP is used for functions only. Exported data symbols in
the CRT interface generally are problematic anyway. And the define form,
while kinda unwieldy, gives you a bit more freedoms to check for it with
ifdef, work around it with undef, etc.
Ok, this is good to know. I did not know what is that preference.
Well I don't know if that's really a generally agreed upon preference or
so, but from looking at our headers, it looks like this has been the
idea/pattern at least.
Anyway, why exported functions are defined via _CRTIMP? Should not be
also be defined via __MINGW_IMP_SYMBOL/dllimport to avoid generating
unnecessary thunk/wrapper for mingw-w64 runtime code?
I think it's a matter of practical tradeoff - the thunk calls isn't a
really big deal here, while having _CRTIMP on declarations and having that
expand to an empty string for building the mingw-w64-crt code mostly does
the right thing - but I'm not sure. I presume it's possible to shave off a
few bytes from a final binary by avoiding that, but it might make things
more messy in general.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
