On Sunday 02 March 2025 18:46:49 Lasse Collin wrote:
> On 2025-02-27 Pali Rohár wrote:
> > I did not wanted to open also this discussion about stat, but as you
> > have opened it, I write some important details, which needs to be
> > taken into account, otherwise another breakage can happen.
>
> Thank you for writing it! It is useful. I apologize if opening this
> thread was bad timing.
>
> > But let this mess as is, all those are underscored functions which MS
> > somehow defined and it is well known API/ABI.
>
> Here was my main confusion a few emails ago and why I opened this
> thread: With UCRT, even _stat64i32 has mingw-w64-specific behavior.
> This felt unexpected because it's a Microsoft function, not POSIX. When
> _stat is defined to _stat64i32, _stat is affected too. It was extra
> confusing because of the inline function that appears only when
> optimizations are enabled.
>
> The trailing slash removal was added in the commit 32ec57d19d96
> ("_mingw_no_trailing_slash() for _stat64i32() and _wstat64i32()") in
> 2017. The commit message only has that one line, giving no hints why the
> change was made. <sys/stat.h> wasn't modified, thus the inline function
> _stat64i32 got out of sync with the code in _stat64i32.c. There is no
> inline function _wstat64i32. Thus, most of the time this commit made no
> difference to the code that calls _stat64i32.
>
> From the mailing list, I only found [1] which explains why 02ad8d9cc38a
> ("fix for previous commit") was made. I didn't find anything else, but
> I didn't search much either.
>
> If these two commits were reverted, I suppose UCRT's _stat64i32 should
> work correctly with optimizations disabled (I didn't test). With
> correctly I mean having whatever behavior the MS CRT function has. As a
> side effect, stat (without underscore) with UCRT would behave better
> when the #defines are such that stat calls _stat64i32.
>
> [1]
> https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/alpine.DEB.2.20.1708031327560.2300%40cone.martin.st/
>
> > Now the interesting part is: How should non-underscored POSIX stat()
> > and fstat() behaves?
> >
> > I think that header file for POSIX stat() and fstat() should follow
> > application definition of _USE_32BIT_TIME_T or the largely used the
> > "-D_TIME_BITS=64" or "-D_FILE_OFFSET_BITS=64" compile flags.
>
> Right, I think four versions are needed because POSIX struct stat
> contains both off_t and time_t (in current POSIX, time_t comes via
> struct timespec, and st_mtime macro expands to st_mtim.tv_sec).
>
> > As the msvcrt.dll's _stat() function has somehow strange behavior of
> > trailing slash, for POSIX stat() purposes, it is needed to define
> > mingw-w64 wrapper.
>
> Correct.
>
> > But as there are 4 variants of "-D_TIME_BITS=64" +
> > "-D_FILE_OFFSET_BITS=64" combinations, it is needed to define 4
> > variants of POSIX stat function. Maybe call them similarly: stat32,
> > stat64, stat64i32 and stat32i64.
>
> It's not ideal to add stat64i32 and stat32i64 into the public
> namespace but maybe it's OK in practice. stat64 comes from LFS so in
> that sense it's a standard name. mingw-w64-headers/crt/_mingw_stat64.h
> has these:
>
> #define stat64 _stat64 /* for POSIX */
> #define fstat64 _fstat64 /* for POSIX */
>
> Maybe it could be safest to put the four functions into private
> namespace, naming them like __mingw64_stat64i32. Then the macro stat
> could have four different values and the macro stat64 two different
> values. On the other hand, changing stat64 to depend on _TIME_BITS is
> AP/ABI change. *sigh* I don't know what makes sense now.
>
> > I think that providing any inline function for any stat* variant would
> > just cause a bigger mess. So I would propose to define 4 mingw-w64
> > wrappers (for each variant) and in header file just add a proper
> > #define stat based on the macros configuration.
>
> I agree.
>
> > Similarly it would be needed to define fstat macro, but should just
> > expand to correct _fstat as there is no need for wrapper.
>
> Sounds good too.
>
> However... if the symbols stat and fstat (and maybe stat64 and fstat64)
> don't exist, will Autoconf find those symbols? AC_CHECK_FUNC is overly
> clever (that is, sort of broken) because it doesn't take a parameter to
> specify the headers to include. Simplified, it tries if this can be
> compiled and linked:
>
> char somefunc(void);
>
> int main(void)
> {
> return somefunc();
> return 0;
> }
>
> I don't know if many packages check if stat and fstat are available
> this way. Maybe many enough assume that they just are available. I hope
> this is overworrying and doesn't matter at all. :-)
>
> I suppose improving the POSIX variants isn't a high priority, but maybe
> the _stat64i32 oddity could be worth fixing sooner than the other
> <sys/stat.h> things.
>
> --
> Lasse Collin
As the discussion started, I decided to I looked at these issues. I have
some WIP changes which defines 4 variants of each fstat/stat/wstat
function, then provides also fstat, stat and wstat function declaration
in header file via __MINGW_ASM_CALL redirect and also exports symbols
from import library. With this way it behaves in the same way as ms
_fstat/_stat/_wstat symbols and functions. This should address also the
autoconf issue which is trying to use functions without including header
file, and also ensure that "stat()" call will be 64-bit + 64-bit if both
-D_TIME_BITS=64 and -D_FILE_OFFSET_BITS=64 are defined. At the same
time I added emulation wrapper for _fstat64/_stat64/_wstat64 function
via WinAPI fallback for older msvcrt libraries which do not have them.
What I have not addressed is the bug in the _mingw_no_trailing_slash
function which you described in the other email. Do you want to look at
my changes or test them?
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
