offset can make sense when whence != SEEK_SET, so the above should
also check for offset < LONG_MIN.
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
found via those links.
[1] https://lists.gnu.org/archive/html/bug-gnulib/2025-04/msg00215.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2025-06/msg00085.html
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w64-public
{ on the same line. I
didn't modify that. There's also some inconsistency between "char *foo"
and "char* foo".
--
Lasse Collin
>From b15762687956b985a4575fe5e90bf8273f453245 Mon Sep 17 00:00:00 2001
From: Lasse Collin
Date: Thu, 8 May 2025 16:20:05 +0300
Subject
This way it works even if setlocale(LC_ALL, ".UTF8") has been used
with UCRT. IsDBCSLeadByteEx(CP_UTF8, x) always returns FALSE, so
nothing else in dirname.c needs to be modified.
---
mingw-w64-crt/misc/dirname.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-crt/m
---
mingw-w64-crt/Makefile.am | 1 +
mingw-w64-crt/stdio/__mingw_fix_stat.h| 13 +
mingw-w64-crt/stdio/__mingw_fix_stat_path.c | 2 +-
mingw-w64-crt/stdio/__mingw_fix_wstat_path.c | 2 +-
mingw-w64-crt/stdio/msvcr110plus_stat32.c | 3 +--
mingw-w6
It returns the code page that the CRT currently uses for filenames.
With UCRT, setlocale(LC_ALL, ".UTF-8") makes the CRT use UTF-8
for filenames, ignoring CP_ACP and CP_OEMCP. Such a setlocale() call
can make the WinAPI filename code page differ from the code page
used by the CRT.
Otherwise the CR
strlen and wcslen return size_t.
---
mingw-w64-crt/stdio/__mingw_fix_stat_path.c | 2 +-
mingw-w64-crt/stdio/__mingw_fix_wstat_path.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/stdio/__mingw_fix_stat_path.c
b/mingw-w64-crt/stdio/__mingw_fix_stat_path.c
i
__mingw_fix_stat_path() also returns NULL if the given path is NULL.
In this case the _statXX function is still called so that it can set
errno = EINVAL or call invalid parameter handler.
---
mingw-w64-crt/stdio/__mingw_fix_stat_path.c | 2 ++
mingw-w64-crt/stdio/__mingw_fix_wstat_path.c | 2 ++
In double-byte character sets, the trail byte of a two-byte character
can be a backslash. If such a two-byte character was at the end of
the pathname, the trailing backslash was incorrectly removed.
The code still removes only one trailing directory separator and thus
stat("directory//", &st) stil
POSIX requires stat("foo/", &st) to fail if "foo" isn't a directory or
a symbolic link to a directory. See ENOTDIR in [1].
The statXX functions, that are used with MSVCRT, already have code
to remove a trailing slash. Extend it to reject non-directories with
ENOTDIR if a trailing slash was removed
On 2025-04-18 Pali Rohár wrote:
> On Friday 18 April 2025 21:27:06 Lasse Collin wrote:
> > On 2025-04-18 Pali Rohár wrote:
> > > On Saturday 25 January 2025 18:17:23 Lasse Collin wrote:
> > > > On 2025-01-25 Pali Rohár wrote:
> > > > > On S
On 2025-04-18 Pali Rohár wrote:
> On Saturday 25 January 2025 18:17:23 Lasse Collin wrote:
> > On 2025-01-25 Pali Rohár wrote:
> > > On Saturday 25 January 2025 12:39:19 Lasse Collin wrote:
> > > > Other things in libmingwex seem friendly to Win9x still. With a
On 2025-04-06 Pali Rohár wrote:
> On Saturday 29 March 2025 18:56:56 Lasse Collin wrote:
> > On 2025-03-29 Pali Rohár wrote:
> > > Problem is that you cannot define _USE_32BIT_TIME_T on UCRT
> > > builds. There are header ifdef checks that combination of
> > &g
On 2025-03-29 Pali Rohár wrote:
> On Saturday 29 March 2025 12:19:19 Lasse Collin wrote:
> > On 2025-03-28 Pali Rohár wrote:
> > > On Saturday 22 March 2025 15:35:48 Lasse Collin wrote:
> > > > If I build with "clang -O2 -fsanitize=cfi -flto" then the
&g
On 2025-03-28 Pali Rohár wrote:
> On Saturday 22 March 2025 15:35:48 Lasse Collin wrote:
> > I verified in MSYS2's CLANG64 environment that -fsanitize=function
> > and -fsanitize=undefined do complain on Windows too.
> >
> > file1.c:
> >
> > struc
have __CRT_BUILDING_STAT which the
relevant .c files would define. But probably (2) is simpler. My ftw
patch could use (2) too.
[1] https://sourceforge.net/p/mingw-w64/mailman/message/59163785/
Message-ID: <20250322153548.402f660f.lasse.col...@tukaani.org>
--
Lasse Collin
__
On 2025-03-20 Pali Rohár wrote:
> On Wednesday 12 March 2025 16:33:42 Lasse Collin wrote:
> > stat.h has "struct stat *" and stat64i32.c has "struct _stat64i32
> > *". On Linux and "clang -fsanitize=function", this kind of argument
> > t
On 2025-03-09 Pali Rohár wrote:
> On Friday 07 March 2025 20:31:09 Lasse Collin wrote:
> > The commit 45bf2cca702b from 2009 added memset calls to zero the
> > stat buffer on failure. That seems unncessary, but the commit
> > message says it fixed something with binutils/bfd.
On 2025-03-07 Pali Rohár wrote:
> On Thursday 06 March 2025 21:40:55 Lasse Collin wrote:
> > On 2025-03-05 Pali Rohár wrote:
> > > 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
>
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
f 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
things.
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 2025-02-28 Lasse Collin wrote:
> On 2025-02-25 Pali Rohár wrote:
> > On Tuesday 25 February 2025 20:11:12 Lasse Collin wrote:
> > > While \\?\...\Partition3 without trailing \ isn't a directory, I
> > > more and more think that it doesn't matter too mu
On 2025-02-25 Pali Rohár wrote:
> On Tuesday 25 February 2025 20:11:12 Lasse Collin wrote:
> > While \\?\...\Partition3 without trailing \ isn't a directory, I
> > more and more think that it doesn't matter too much if opendir
> > works on it still. It's so tiny
rrently mingw-w64
breaks UCRT's _stat when building with optimizations disabled.
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On 2025-02-25 Pali Rohár wrote:
> On Tuesday 25 February 2025 20:11:12 Lasse Collin wrote:
> > MSVCRT's _stat() fails with "directory/", but in POSIX a trailing
> > slash should work for directories (and only for directories).
> > mingw-w64-crt/stdio/_st
n't follow reparse points. UCRT's _stat() does
(on symlink or junction loops it fails with ENOENT, not ELOOP).
On 2025-02-23 Lasse Collin wrote:
> On 2025-02-23 Pali Rohár wrote:
> > On 2025-02-23 Lasse Collin wrote:
> > > The fact that something else does it wrong doe
On 2025-02-24 Lasse Collin wrote:
> I attached a patch to the new dirent.
And now fixed a copypaste error. :-|
--
Lasse Collin
From 7626a912b2d95a090e401b311ec9a3edf771aed7 Mon Sep 17 00:00:00 2001
From: Lasse Collin
Date: Mon, 24 Feb 2025 17:35:03 +0200
Subject: [PATCH] ... Fix copypa
On 2025-02-23 Lasse Collin wrote:
> On 2025-02-23 Pali Rohár wrote:
> > WinAPI \\?\ has meaning to not do any normalization, so consumer
> > should not add or remove some characters.
[...]
> In the new dirent, GetFullPathNameW converts mixed \/ usage to \, then
> * is append
[desktop apps only]":
https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversion
GetVersionExA says "[desktop apps | UWP apps]":
https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa
Reality might differ fro
On 2025-02-22 Pali Rohár wrote:
> On Saturday 22 February 2025 18:12:36 Lasse Collin wrote:
> > On 2025-02-22 Pali Rohár wrote:
> > > On Saturday 22 February 2025 16:03:42 Lasse Collin wrote:
> > > > On 2025-02-18 Pali Rohár wrote:
> > > > &g
On 2025-02-22 Pali Rohár wrote:
> On Saturday 22 February 2025 16:03:42 Lasse Collin wrote:
> > On 2025-02-18 Pali Rohár wrote:
> > > On Tuesday 18 February 2025 23:32:54 Lasse Collin wrote:
> > > > On 2025-02-18 Pali Rohár wrote:
> > > > > Ju
On 2025-02-18 Pali Rohár wrote:
> On Tuesday 18 February 2025 23:32:54 Lasse Collin wrote:
> > On 2025-02-18 Pali Rohár wrote:
> > > Just one test case, can you check that your new readdir()
> > > function is working correctly on these two paths?
> > >
&
On 2025-02-18 Pali Rohár wrote:
> On Tuesday 18 February 2025 23:32:54 Lasse Collin wrote:
> > With one partition, opendir fails with EIO, and GetLastError returns
> > ERROR_UNRECOGNIZED_VOLUME (1005). That seems to mean that there's no
> > recognized file system. I don
e
get_d_type() better and helped me spot the need for get_code_page().
> I was just surprised that FILENAME_MAX is in C99, I did not know about
> it. I thought that it is MS invention, together with that value 260.
> Now I checked and this macro is available since C89. So it is really
>
On 2025-02-18 Lasse Collin wrote:
> Python's stat.S_IFBLK and stat.S_ISBLK(mode) use the values from
> . Thus, MSYS2-Python uses 0x6000 and UCRT64-Python
> uses 0x3000.
Python/fileutils.c hardcodes 0x6000:
https://github.com/python/cpython/blob/51d4bf1e0e5349090da72721c8
On 2025-02-17 Pali Rohár wrote:
> On Monday 17 February 2025 17:37:17 Lasse Collin wrote:
> > I suppose lstat() shouldn't follow any reparse points.
>
> That is a question for which I do not have answer.
One would need to figure out what is the least surprising behavior.
On 2025-02-16 Pali Rohár wrote:
> On Sunday 16 February 2025 19:32:24 Lasse Collin wrote:
> > (There's no lstat() to detect symlinks or readlink() to read them.)
>
> I know. Maybe for future it would be nice to have lstat() call.
> Implementation can be straightforward, ope
On 2025-02-16 Pali Rohár wrote:
> On Sunday 16 February 2025 12:23:56 Lasse Collin wrote:
> > On 2025-02-15 Pali Rohár wrote:
> > > IMHO, we should not use FILE_ATTRIBUTE_* for determining d_type
> > > (except the FILE_ATTRIBUTE_DIRECTORY which defines directory)
_SEQUENTIAL is there.
There seems to be a bug when opening junctions with both old and new
dirent. The old code fails at readdir with EINVAL. The new code fails
at opendir with EACCES. I don't know how to fix it or how big issue it
is in practice. Both old and ne
in mingw-w64 might cause
incompatibility somewhere, especially if NAME_MAX happened to be used
in some DLL API header. *sigh*
--
Lasse Collin
From 0d98dea4c49e80c30a81c39068ece3ea5a0e5b9a Mon Sep 17 00:00:00 2001
From: Lasse Collin
Date: Sat, 15 Feb 2025 18:02:45 +0200
Subject: [PATCH 1/3] crt: dirent: Update
limitations with CP_UTF8 shouldn't be an issue.
The new dirent code doesn't work on Win9x, but it was quick to test on
those anyway.
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
ntion in POSIX. d_name has an unspecified size and
the sizeof operator shouldn't be used on it. The sizeof is mentioned in
the "Rationale" section:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/dirent.h.html
> On Thu, 16 Jan 2025, Lasse Collin wrote:
>
>
On 2025-02-12 Martin Storsjö wrote:
> On Thu, 16 Jan 2025, Lasse Collin wrote:
>
> > The dirent functions are defined in POSIX, and POSIX clearly
> > specifies that no POSIX function shall set errno to zero.
>
> Hmm, I haven't dug very deep for references aroun
I think it would be
good if you could review my dirent update. It needs some tweaking and
testing before I can send it. It's still clearly based on the old code
but the modifications are big enough that there's no point to send it
as a series of patches. *If* you
ch would fall back to the 8.3 name if
conversion of the long name fails. I suppose it's a more sensible
fallback for some apps than imaginary names from best-fit mapping.
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Packages that
use Gnulib might have a setlocale() override still though.)
To keep things simpler, UTF-8 locales ideally wouldn't be used unless
ACP is UTF-8 (set in application manifest or globally in Windows
settings). It's not that simple tho
On 2025-01-25 Pali Rohár wrote:
> On Saturday 25 January 2025 18:52:26 Lasse Collin wrote:
> > Even if wide char functions were always used to read filenames,
> > perhaps AreFileApisANSI() needs to be taken into account in
> > readdir() to determine if the wide char name
On 2025-01-25 Lasse Collin wrote:
> On 2025-01-25 Pali Rohár wrote:
> > Also what could be different is that _findfirst may be affected by
> > setlocale function as IIRC UCRT supports changing process locale but
> > only for UCRT functions.
> >
> > Another importa
On 2025-01-25 Pali Rohár wrote:
> On Saturday 25 January 2025 12:39:19 Lasse Collin wrote:
> > The CRT functions prodide timestamps in time_t while Win32 API
> > provides FILETIME. Perhaps the conversion wastes time. The dirent
> > functions don't need file timestam
On 2025-01-17 Pali Rohár wrote:
> On Friday 17 January 2025 15:22:30 Lasse Collin wrote:
> > Another possible change could be to call FindFirstFileW directly
> > instead of going via _wfindfirst.
>
> Personally I would prefer to stay with _wfindfirst as it is from
&
On 2025-01-16 Pali Rohár wrote:
> On Thursday 16 January 2025 18:32:08 Lasse Collin wrote:
> > I see that sizeof(DIR) depends on _USE_32BIT_TIME_T because DIR
> > contains _finddata_t or _wfinddata_t. Luckily no one is supposed to
> > access that structure directly.
>
On 2025-01-16 Lasse Collin wrote:
> +++ b/mingw-w64-headers/crt/dirent.h
[...]
> + unsigned intdd_errno;
dd_errno should be int. I had had a different member there at one point
and apparently didn't fix the type.
--
L
This keeps the code simpler when "struct dirent" is modified.
---
mingw-w64-crt/misc/dirent.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/mingw-w64-crt/misc/dirent.c b/mingw-w64-crt/misc/dirent.c
index 20266966a..8bda0b169 100644
--- a/mingw-w64-crt/misc/dirent.c
++
Also update two comments in the moved structure to refer to _wfindnext
instead of _findnext.
DIR and _WDIR are supposed to be opaque structures which applications
shouldn't access directly. Also, their arrangement was incorrect from
applications' point of view if _USE_32BIT_TIME_T was defined due
It was needed for the DIR and _WDIR structures.
---
mingw-w64-headers/crt/dirent.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/mingw-w64-headers/crt/dirent.h b/mingw-w64-headers/crt/dirent.h
index 95050e61c..e7717ffaa 100644
--- a/mingw-w64-headers/crt/dirent.h
+++ b/mingw-w64-headers/crt
This makes the dirent functions usable in applications that have
been marked as long path aware in their application manifests.
---
mingw-w64-crt/misc/dirent.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-crt/misc/dirent.c b/mingw-w64-crt/misc/dirent.c
index
The dirent functions are defined in POSIX, and POSIX clearly specifies
that no POSIX function shall set errno to zero. If a caller of
readdir() wants to distinguish errors from a successful end of the
directory, the caller must set errno = 0 before calling readdir().
Don't set errno = ENOENT if th
NAME_MAX is a POSIX constant; Windows doesn't define it. For this
reason, assume that NAME_MAX is only about filenames in multibyte
representation. In the UTF-8 code page, filenames can be up to
255 * 3 bytes excluding the terminating null character. (It's not
255 * 4 because four-byte UTF-8 charac
---
mingw-w64-crt/misc/dirent.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mingw-w64-crt/misc/dirent.c b/mingw-w64-crt/misc/dirent.c
index 4897cf492..a5d594cc3 100644
--- a/mingw-w64-crt/misc/dirent.c
+++ b/mingw-w64-crt/misc/dirent.c
@@ -11,7 +11,7 @@
* Updated by Jer
Skip filenames that cannot be converted to the active code page in
a lossless manner. If the end of the directory is successfully reached,
return NULL with errno = EILSEQ for one time. If readdir() is called
again, errno won't be modified again.
If a multibyte filename is too long to fit into stru
---
mingw-w64-crt/misc/dirent.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mingw-w64-crt/misc/dirent.c b/mingw-w64-crt/misc/dirent.c
index 4f9c61b0c..20266966a 100644
--- a/mingw-w64-crt/misc/dirent.c
+++ b/mingw-w64-crt/misc/dirent.c
@@ -73,7 +73,13 @@ _topendir (c
rving
a flag variable for it in the DIR structure could be good.
Lasse Collin (10):
crt: dirent: Clean up white space
crt: dirent: Use NULL instead of casting 0 to a pointer
crt: dirent: Fix errno usage
crt: dirent: Check the return value of _tfullpath
crt: dirent: Use memset to initialize the
---
mingw-w64-crt/misc/dirent.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/mingw-w64-crt/misc/dirent.c b/mingw-w64-crt/misc/dirent.c
index a5d594cc3..215b0b0b6 100644
--- a/mingw-w64-crt/misc/dirent.c
+++ b/mingw-w64-crt/misc/dirent.c
@@ -50,13 +50,13 @@ _
ike:
#ifdef _DIRENT_LOSSY
# define opendir _opendir_lossy
#endif
Apps could then #define _DIRENT_LOSSY and the code would be *source
compatible* with both old and new MinGW-w64. If an application
itself doe
ioning with only header macros, all
participants have to co-operate. Ideally one doesn't use this kind of
data types in API/ABI at all.
> > I (hopefully) fixed dirent issues in Gnulib:
> >
> > https://lists.gnu.org/archive/html/bug-gnulib/2025-01/msg00087.html
This didn
t, how to notify that both need to be
rebuilt at the same time.
I (hopefully) fixed dirent issues in Gnulib:
https://lists.gnu.org/archive/html/bug-gnulib/2025-01/msg00087.html
One cannot copy the code to MinGW-w64 for license reasons but we can
learn from feedback on bug-gnulib still.
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
This is broken. Some code pages don't allow WC_NO_BEST_FIT_CHARS.
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
---
mingw-w64-crt/misc/wctob.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mingw-w64-crt/misc/wctob.c b/mingw-w64-crt/misc/wctob.c
index d694cb527..b19effb99 100644
--- a/mingw-w64-crt/misc/wctob.c
+++ b/mingw-w64-crt/misc/wctob.c
@@ -25,5 +25,5 @@ int wctob (wint_t wc )
Previously these functions failed with EOF or EILSEQ only when there
was no best-fit character available and a replacement character had
been substituted. Now these fail if conversion isn't lossless.
---
mingw-w64-crt/misc/wcrtomb.c | 2 +-
mingw-w64-crt/misc/wctob.c | 2 +-
2 files changed, 2 i
ructs in MinGW-w64's be changed or are they all
part of the ABI that shouldn't be broken? In struct dirent, extending
"char d_name[260];" would allow long UTF-8 filenames to fit.
--
Lasse Collin
___
Mingw-w64-public maili
There is more information about the issue at <https://worst.fit/>.
Seems that it may have been released in mid-December already.
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourcefor
On 2024-11-27 Pali Rohár wrote:
> I think that we should not ignore memory allocation failures.
I agree. I'm not able to comment the implementation ideas though.
--
Lasse Collin
___
Mingw-w64-public mailing list
Mingw-w6
On 2024-11-12 Lasse Collin wrote:
> On 2024-11-12 Pali Rohár wrote:
> > At least every character which is by best-fit mapped to double quote
> > has to be replaced.
>
> Yes, that seems mandatory.
This alone might not be enough because a double quote can be escaped
w
n is worth reading. The intention is that
argv[] from main() is ignored.
The UTF-8 conversion returns NULL if there are unpaired surrogates.
That is, the resulting argv[] may have NULL pointers.
https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gutf8.c?ref_type=heads#L1077
--
Lasse Collin
On 2024-11-12 Pali Rohár wrote:
> On Monday 11 November 2024 22:10:01 Lasse Collin wrote:
> > If permissive mode can be enabled the same way as _dowildcard works,
> > then argv[] could be constructed with the same code as in strict
> > mode. The current crtexe.c in master has
On 2024-11-12 LIU Hao wrote:
> 在 2024-11-12 22:49, Lasse Collin 写道:
> > The _exit(255) trick is clearly not an acceptable default. My patch
> > should be reverted until a better one is made. It might be that all
> > apps that want safe argv[] for main() will need something s
hould wait and see if Microsoft
will do something about this issue in 1-2 months. With bad luck even a
milder fix might result in unwanted differences in command line
handling between MinGW-w64 and MSVC built executables.
--
Lasse Collin
___
Mingw-w6
non-bijective.
Yes. Documentation of WideCharToMultiByte() says that in WinXP the
conversion was bijective but it was changed in Vista to not produce
invalid UTF-8 (the code points of surrogates are invalid UTF-8).
I suppose that in practice it should often be good enough that s
78 matches
Mail list logo
