On 2025-03-05 Pali Rohár wrote:
> 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.

Sounds great. :-)

> Do you want to look at my changes or test them?

Yes, I'm interested. It might take a few days depending on how I have
time.

> What I have not addressed is the bug in the _mingw_no_trailing_slash
> function which you described in the other email.

Earlier I tried adding a check for malloc() failure and making stat()
fail with ENOTDIR if a slash had been removed and the result wasn't a
directory. These were fairly simple changes, so if you didn't implement
those, I can try on top of your patches.

I'm not sure if it is worth adding support for removing more than one
slash at this point. It would need some care since the code has to keep
one slash in some cases (I don't want add new bugs).

There's also one more tiny bug in the slash removal: with double-byte
code pages, the second byte of a double-byte character can be \. The
correct way to handle it would be using IsDBCSLeadByteEx like in
mingw-w64-crt/misc/dirname.c. That makes things more complicated. Or
one could maybe convert to wide char and call wstat(), but that's more
complicated too. I don't know if it's worth it in practice at this
point (UCRT doesn't need this code).

One more tiny bug: mingw-w64-crt/misc/dirname.c calls AreFileApisANSI to
determine the filename code page, but it doesn't handle the UCRT UTF-8
locale case. I wonder if it made sense to have a separate file for
"DWORD __mingw64_filesystem_cp(void)" which dirname.c and dirent.c
could use. The UTF-8 locale without UTF-8 manifest is hopefully not a
common use case though.

-- 
Lasse Collin


_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to