On Monday 19 September 2022 16:50:33 Martin Storsjö wrote: > On Mon, 19 Sep 2022, Pali Rohár wrote: > > > On Monday 19 September 2022 15:33:45 Martin Storsjö wrote: > > > On Sat, 17 Sep 2022, Pali Rohár wrote: > > > > > > > --- > > > > mingw-w64-crt/Makefile.am | 3 +++ > > > > mingw-w64-crt/stdio/ucrt__scprintf.c | 21 +++++++++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt__snprintf.c | 21 +++++++++++++++++++++ > > > > mingw-w64-crt/stdio/ucrt__snscanf.c | 21 +++++++++++++++++++++ > > > > 4 files changed, 66 insertions(+) > > > > create mode 100644 mingw-w64-crt/stdio/ucrt__scprintf.c > > > > create mode 100644 mingw-w64-crt/stdio/ucrt__snprintf.c > > > > create mode 100644 mingw-w64-crt/stdio/ucrt__snscanf.c > > > > > > I fail to see the motivation for these three patches. > > > > > > Sure there are inconsistencies currently (how we have a non-inline > > > _vscprintf today but _scprintf is inline), but for all the existing ones, > > > we > > > consistently have either inline or extern definition - but not both. > > > > For different checks (like in autoconf) it is needed to have functions > > linkable/exported from standard library. As these checks are doing > > linking without including header files. This is reason why there is e.g. > > snprintf function in mingw-w64 crt library. > > Yes, I know that this is the reason for why I moved those functions there. > But if moving other functions, I'd like to hear that specifically this, or > something else, is the motivation. > > We didn't move all inline functions into external ones, only ones that we > know that common autoconf scripts check for. > > Also, most of them, which are standard C functions, are such that the > standard mandates that they have extern linkage - but _scprintf isn't one of > those that the standard say anything about. > > > And for optimizations, it is really not a good idea to use another > > function wrapper which just call another function. This is reason why > > functions are defined as inline. > > So far, we have mostly not had this, not for any of the UCRT functions at > least. > > If we suddenly want that, then this should be specifically labelled as a > patch that explicit does that change, so that it can be evaluated at face > value, not sneakily trying to change policy/common style as part of a > different change. > > And if we really are changing policy to duplicate function definitions for > performance reasons, I'm sure that the main printf/snprintf functions would > be a better target to start with, than _scprintf. And then it would also be > nice to have any actual numbers to back it up, to justify the added > maintaince burden of duplicate definitions. > > > > So while some reshuffling might be warranted - if there's a good reason > > > for > > > it - I'd prefer to make them either entirely inline or entirely extern, > > > when > > > doing such reshuffling. > > > > > > // Martin > > > > I think that C99 requires that inline functions need to have also > > non-inline variant for external linkage. > > There are many, many different variants of inline behaviour - C89 inline, > C99 inline, static inline, extern inline, gnu_inline, etc. There's a couple > different styles used here; all the inline functions that we're talking > about here have static inline linkage - which doesn't require any external > linkage version of the function. > > When dealing with the other ones that do require external linkage to be > present, there's a whole rat's nest of potential issues, since sometimes one > compiler never tries to use the external version, but other compilers do, > etc. > > > Anyway, my motivation was to build mingw-w64 runtime without dependency > > on particular msvcrt/ucrt CRT code, so CRT dependent code would be > > constructed at application compile time. And for this, it is needed that > > mingw-w64 runtime/helper functions would not use any inline ucrt > > function, so it would be CRT independent. > > Ok, so this is the core of what you're working towards - good to have that > out in the clear. > > What runtime do you specifically mean, which currently is CRT dependent but > should be independent? Currently, libmingwex.a and all the other > mingw-w64-crt bits should be, as far as I know, CRT independent (but there > can of course be bits that I've missed). All those bits are specifically > compiled with "-D__MSVCRT_VERSION__=0x700" today, so regardless of what is > set as default version in the headers, these should always be built the same > way today. The intent is that all symbols that those refer to should be > provided by the various lib*crt*.a. > > If you mean other runtimes (libgcc, libstdc++, libc++, winopthreads etc), > then reducing use of inline functions does reduce the variation between > different CRT choices - yes - but it doesn't elimitate it entirely, since > there are public structs that have different layout and different members > depending on the CRT choice. For static libraries, something like that might > help, but for DLL builds of them, the DLL is already finalized so there's > not much that can be changed after the fact. > > Can you elaborate on how you meant to construct such code at application > compile time? > > // Martin
Hello! Thank you very much for all those details. I did not investigated everything yet, just small subset. But runtime I mean all of them which you mentioned (from mingw-w64-crt to libgcc/stdc++...). Public structures and dll libs are problematic. I was planning to look at it what is different, how and what can be done to achieve binary compatibility. The main issue which I see is that if you "compile" source code (gcc -c) of some application then it already reference ucrt symbols (if mingw-w64 runtime was compiled for ucrt) because header files automatically inline some ucrt functions. Same for msvcrt. I see that mingw-w64 crt is compiled with "-D__MSVCRT_VERSION__=0x700" which you mentioned, and which should "workaround" above issue. So if this issue can be "fixed" then building static libraries can be CRT independent. And back to the list, function _snprintf is used by lot of applications as this is "native" msvcrt function and because msvcrt does not provide real C99 snprintf. So that is why I chose this one. Just for information. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
