On Fri, 26 Apr 2024, Jacek Caban wrote:
On 25.04.2024 23:11, Pali Rohár wrote:
And also it would allow to create object file which
calls "_findfirst" symbol and then link it with any mingw-w64 CRT import
library.
Mixing crts is problematic for many reasons, this is just one of them. And if
one really needs to go that far, it's better to just use *32 or *64 variant
explicitly, which would entirely avoid the confusion and should be possible
with current crt.
I think it is better to have stable symbol meaning than to have symbol
alias matching what the headers default to. Stable symbol meaning can be
an invariant in this case. But symbol matching with header file is not
stable as application can change it by -D_USE_32BIT_TIME_T.
What do you think? Does it make sense?
Sure, an application can change it on per-file basis, but it's way more
likely that it doesn't and just uses the default. If we provide a different
default behavior in headers, why wouldn't we reflect that in crt part?
FWIW, I just dug up the history of these aliases, and this has clearly
been the intent so far (even if the exact symbol it references isn't
entirely right wrt _findfirst at least) - see the following commits:
commit a648ec2af9aa731a264ad00223940f5cd67ca285
Author: Martin Storsjö <mar...@martin.st>
Date: Sun Nov 12 22:41:31 2017 +0200
crt: Map _find{first,next} to _find{first,next}32 on ucrtbase
commit 42aa3325fcfee934d7b706b701e49ee7a3c94982
Author: Liu Hao <lh_mo...@126.com>
Date: Tue Mar 30 22:19:33 2021 +0800
crt: Add symbols for POSIX time functions and find{first,next} functions
commit e37b315bc039a10507c5cb1046d6b891506022be
Author: Liu Hao <lh_mo...@126.com>
Date: Mon Apr 5 18:18:54 2021 +0800
include/_mingw.h.in,crt: Extend `time_t` to 64 bits for UCRT for 32-bit
targets
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
