> we are capable to handle dll-imports without the proper > decoration of the symbol.
I understand why you want to have the stubs. This made more sense to me once I saw that __builtin_memset ends up using them to call __imp_memset. > If a symbol is marked as dllimport, it means it becomes part of the > DECL itself. So we get conflicts with people simply doing prototypes > without. By this reason - and some issues about builtin-optimization > for such symbols - we decided to remove by those symbols the CRTIMP > decoration. Argh! Yes, I see what you mean. Even if you aren't using posix, if you have your own definition for any of these functions, warning messages can appear. Unless the _CRTIMP def comes after the non-imp. I'm trying to decide what is the proper balance here: Side A (Change to use _CRTIMP or _POSIXPREFIX): People who use headers that conflict with ours AND who use our headers first will get easily suppressed warning messages. Side B (Leave as is): We have runtime performance issues with any posix-ish functions. Given that my current project is so performance sensitive, I'm heavily biased towards B. But maybe this one should just sit for a while. Perhaps a better approach will occur to me. > And I kindly ask not to touch the default behavior here as it might > cause breakages at pretty unexpected places. I didn't even start trying to change stdio.h until I heard back from you. This seemed so odd that I had to ask. If we did add some type of #define here, it would also be a good place to document all this. I'm a big believer in capturing this kind of knowledge, but you've got to have a place where people will find it. dw ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
