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
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
