This would allow us, for example, override value of ___MSVCRT_VERSION__ when
compiling tests. I think It would make sense to define it to the value
corresponding to CRT specified with --with-default-msvcrt configure option?
- Kirill Makurin
From: Martin Storsjö
is incorrect?
- Kirill Makurin
From: Martin Storsjö
Sent: Monday, July 14, 2025 5:53 AM
To: Kirill Makurin
Cc: mingw-w64-public
Subject: Re: [Mingw-w64-public] New implementation for C95 conversion functions
On Sat, 12 Jul 2025, Kirill Makurin wrote:
> ```
>
ject (from which I
based both implementation and tests), but forgot to mirror the fix in sent
patches.
I attached a patch which should fix it. I am only unsure whether it is OK to
check for _UCRT, maybe checking __MSVCRT_VERSION__ would be better?
- Kirill Makurin
___
and older CRTs.
- Kirill Makurin
[1] https://github.com/maiddaisuki/mingw-w64/actions/runs/16165302800
From 88e0c9a47af9f5fe00d1426361cc80fb97a5bed2 Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Wed, 9 Jul 2025 17:04:34 +0900
Subject: [PATCH 1/8] crt: new implementation for C95 conversion
Thanks for letting me know. I'll look into them and will send updated patches.
- Kirill Makurin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
srtowcs (buffer, &str, buffer_size + 1, &state);
or the same logic for wcsrtombs. I don't think there are many (if any) people
who try to convert strings char-by-char, let alone people who would call
mbrtowc with anything but MB_CUR_MAX.
- Kirill Makurin
orrectly convert the first character in str, however, since `mbrtowc`
returns 2, it skips two bytes in str instead of one as it should. The result is
either incorrectly converted string or conversion failure, depending on what
byte is pointed to by str+2.
- Kirill Makurin
___
we go that far, we can also fix return value of `mbrtowc`.
- Kirill Makurin
[1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/mbrtowc.html
From c2ea3a177dc5795b5b765705d932b05b901abea4 Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Mon, 30 Jun 2025 16:46:32 +0900
Subjec
8 and this is much
more trouble to implement, I doubt anyone would even try.
- Kirill Makurin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
call
consumed 1 byte to complete it, so the return value is 1.
Any ideas here? Or should I try my luck on gnulib list?
I guess consistency with CRT would be preferred on Windows. I also attached a
simple program which you can compile with CRT or glibc to observe this.
- Kirill Makurin
[1]
mingw-w64.
--
I could have missed something, but this should be enough to have an idea how
locales work on Windows and what kinds of issues we have in CRT.
- Kirill Makurin
[1] https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-makelcid
[2] https://learn.m
This should fix error when compiling C++ modules[1].
- Kirill Makurin
[1] https://github.com/mingw-w64/mingw-w64/issues/99
From c3d9c047a80ee40545388a0359f25fa3d1f4a95e Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Sun, 22 Jun 2025 04:01:04 +0900
Subject: [PATCH] winpthreads: fix
en on 64-bit
systems.
- Kirill Makurin
From: pali.ro...@gmail.com
Sent: Friday, June 20, 2025 9:11 PM
To: Kirill Makurin
Cc: LIU Hao ; mingw-w64-public@lists.sourceforge.net
; Martin Storsjö
Subject: Re: [Mingw-w64-public] [PATCH v2 00/13] Fix stat functions
4-bit UCRT provides
32-bit _fstat32 symbol.
```
Even if 64-bit CRTs do not allow 32-bit time_t, _[f]stat*32 symbols are still
present in UCRT.
- Kirill Makurin
From: LIU Hao
Sent: Friday, June 20, 2025 8:40 PM
To: Kirill Makurin; mingw-w64-public@lists.sourc
I unfortunately do not have a 32-bit msvcrt.dll to check, but listing symbols
from msvcrt.dll in C:/Windows/SysWOW64 directory also is missing _[f]stat*32
symbols.
It would be good if someone could check 32-bit version of msvcrt.dll on
different Windows versions.
- Kirill Makurin
Running `grep _f*stat` on list of symbols I get from `dumpbin -exports
msvcrt.dll` (Windows 11) I get the following:
```
_fstat
_fstat64
_fstati64
_stat
_stat64
_stati64
```
It seems there is also no real _[f]stati32 and _[f]stat64i32 symbols. Are they
taken care of?
- Kirill Makurin
I think it is worth to report this issue to autoconf-bug mailing list first.
I'll do it.
If they will not want to fix this, we can simply
```
#ifdef pid_t
#undef pid_t
#endif
```
since we typedef it to the same base type as AC_TYPE_PID_T #define's it.
- Kiri
x27;winpthreads')
else
threads = dependency('threads')
endif
```
to use POSIX threads with both mingw-w64 and msvc.
So far, the only project that comes to mind to use this is glib. I think it
allows to force usage of POSIX threads.
- Kirill Makurin
c` and `wcrtomb` respectively.
I suggest we start a new discussion in a new thread. I have some other details
regarding CRT's locale support since I am currently working on code which
implements POSIX locale functions on top of Win32 and CRT.
- Kirill Makurin
From: LI
-default-msvcrt=ucrt. Things seem to work well.
- Kirill Makurin
[1]
https://learn.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
From: LIU Hao
Sent: Sunday, June 8, 2025 12:19 AM
To: Kirill Makurin; mingw-w64-public
Subject: Re
also
includes mb*towc* and wc*tomb* functions.
- Kirill Makurin
From: LIU Hao
Sent: Saturday, June 7, 2025 6:21 PM
To: Kirill Makurin; mingw-w64-public
Subject: Re: [Mingw-w64-public] Inconsistent behavior of btowc with "C" locale
在 2025-6-7 02:04, Kirill
Oh, you are right, it does sign-extend the result.
I see that declarations of `btowc` and `wctob` in wchar.h do not have `_CRTIMP`.
Does it mean they just need to be removed from import libraries?
It also seems my second patch is no longer needed.
- Kirill Makurin
Using range check will prevent best-fit conversion. I think it would be
preferrable in this case.
- Kirill Makurin
From: Kirill Makurin
Sent: Saturday, June 7, 2025 1:02 AM
To: LIU Hao ; mingw-w64-public
Subject: Re: [Mingw-w64-public] Inconsistent behavior of
up with using 20127, so we would perform best-fit
conversion in "C" locale. I was wrong.
We could you either 28591 or range check just like in btowc. Which one would
you prefer?
- Kirill Makurin
From: LIU Hao
Sent: Saturday, June 7, 2025 12:39 AM
To: K
I have updated my initial patch, if you're OK with it.
There is second patch which should add emulation of btowc and wctob for
msvcrt.dll. I have not tested it, sorry for that.
- Kirill Makurin
From: Kirill Makurin
Sent: Friday, June 6, 2025 6:47 PM
To:
I can update patch I initially attached to:
For btowc, check for value to be in range [0,255] instead of [0,127].
For wctob, remove range check and use code page 20127 (ASCII) for conversion
(so it matches CRT's best-fit behavior).
- Kirill Makurin
From
`
If pthread_compat.h is later included, this results in syntax error in
```
#ifdef _WIN64
typedef __int64 pid_t;
#else
typedef int pid_t;
#endif
```
We could guard typedef with `#ifndef pid_t`, or add the following just above:
```
#ifdef pid_t
#undef pid_t
#endif
```
- Kirill Makurin
You are right. `libtool --mode=execute` is no longer needed.
I forgot that libtool creates wrapper executables which handle search path.
I attached update patch.
- Kirill Makurin
From: LIU Hao
Sent: Tuesday, June 3, 2025 7:11 PM
To: Kirill Makurin; mingw-w64
e might need to check return value of `___lc_codepage_func()`.
However, should we return WEOF for bytes in range 128-255? I think it would be
good to be consistent with MSVCRT's behavior, which seems to do so.
- Kirill Makurin
From: LIU Hao
Sent: Tuesday, Jun
This is a good idea. Plain `LDADD` (not `LIBADD`) is used to add libraries to
all programs in current Makefile.am.
I have attached updated patch.
- Kirill Makurin
From: LIU Hao
Sent: Tuesday, June 3, 2025 12:47 PM
To: mingw-w64-public@lists.sourceforge.net
replacement's behavior to match CRT.
Note: manpage link you attached is for `POSIX Programmer's Manual`, not C
Library (Library Functions Manual).
- Kirill Makurin
From: LIU Hao
Sent: Tuesday, June 3, 2025 8:19 PM
To: Kirill Makurin; mingw-
ge [128,255] with "C"
locale. The behavior of btowc not returning WEOF for values in range [128,255]
seems to be new. Existing manpages do not mention it.
- Kirill Makurin
From: LIU Hao
Sent: Tuesday, June 3, 2025 7:35 PM
To: Kirill Makurin; mingw-w6
regarding *correct* return value in "C" locale. Actually,
there is a comment in Microsoft headers saying that _BLANK only handles space
character and that tab should be handled separately.
- Kirill Makurin
____
From: Kirill Makurin
Sent: Sunday, June 1, 2025
ype: 0
```
UCRT, locales other than "C":
```
_isctype: 1
iswctype: 0
```
If I am correct, both should return non-zero in "C" locale.
I compared this to behavior of is[w]blank in glibc. They always return non-zero.
- Kirill Makurin
#define __USE_MINGW_ANSI_STDIO 0
#define _C
eChar(20127, ...):
While experimenting, I noticed that `MultiByteToWideChar` when used with code
page 20127 succeeds even when string contains characters in range 128-255. It
acts is if it would call `toascii()` before performing conversion of a single
character.
See commit message.
- Kirill Makurin
From a0a35f2d0eefed69c2d789eb50fb222b9566768a Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Sun, 1 Jun 2025 15:54:23 +0900
Subject: [PATCH] winpthreads: make testing shared library work
Running `make check` when configured with `--disable-static
Please ignore this message. I sent it a few days ago and apparently it got
delivered only now.
- Kirill Makurin
From: Kirill Makurin
Sent: Sunday, May 4, 2025 6:52 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] [V2] winpthreads
rting
with mavcr80.dll and some OS-specific versions of msvcrt.dll (I believe it is
emulated for CRTs which do not have it).
- Kirill Makurin
From: Kirill Makurin
Sent: Tuesday, April 22, 2025 5:20:02 PM
To: mingw-w64-public
Subject: [Mingw-w64-public
when corresponding source file is compiled.
- Kirill Makurin
From 04b76b913bdf1ec0b27ef7c6e9525cf46ddc8ad4 Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Tue, 22 Apr 2025 09:20:39 +0900
Subject: [PATCH 01/11] winpthreads: fix `make dist`
libwinpthread_la_SOURCES lists header files which are
Please let me know if patches in 0005.txt and 0006.txt are ok. I would like to
reorder them before large changes.
- Kirill Makurin
From: LIU Hao
Sent: Saturday, April 19, 2025 11:05 PM
To: Kirill Makurin; mingw-w64-public@lists.sourceforge.net
Subject: Re
uld expect unsuffixed versions to use time_t of the
corresponding size.
- Kirill Makurin
From: LIU Hao
Sent: Saturday, April 19, 2025 11:05 PM
To: Kirill Makurin; mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] winpthreads: add s
`errno` to `ERANGE` in clock_gettime32 if
time does not fit in 32bit time_t. Is there any better `errno` value for this?
- Kirill Makurin
From: LIU Hao
Sent: Saturday, April 19, 2025 8:35 PM
To: mingw-w64-public@lists.sourceforge.net; Kirill Makurin
Subject: Re: [Mingw-
s macro is
defined?
I would like to move definition of `WIN32_LEAN_AND_MEAN` from Makefile.am to
source files (just before `#include `.
- Kirill Makurin
From f85cac55917dd8ec05ff0dbbbe910f41eb5b6512 Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Tue, 15 Apr 2025 03:31:25 +0900
Subject:
ation
(https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/create-locale-wcreate-locale)
also
specifies that this function may be declared in `wchar.h`.
- Kirill Makurin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
"pthread_compat.h"` to not duplicate it in pthread_time.h, but I think it could
be useful to make pthread_time.h usable on its own.
- Kirill Makurin
From: LIU Hao
Sent: Sunday, February 9, 2025 12:43:20 AM
To: mingw-w64-public@lists.sourceforge.net
Sorry, I forgot to attach patches.
From: Kirill Makurin
Sent: Thursday, February 20, 2025 2:33 AM
To: mingw-w64-public
Subject: winpthreads: a few more header file cleanups
Patch 1: remove old, commented out typedef for `pthread_t`.
Patch 2: move `SIG_BLOCK
th MSVC as they use
`pthread_t` as if it was an old struct removed in patch 1.
I don't know if anyone uses these tests the way the are now, so I think
integrating them with Automake could be useful.
- Kirill Makurin
___
Mingw-w64-public mailing
ts to be cautious.
- Kirill Makurin
From: LIU Hao
Sent: Tuesday, February 18, 2025 10:37 PM
To: Kirill Makurin; mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] make sure WINPTHREAD_API is correctly defined
in pthread_time.h
在 2025-02-16
Hi,
mingw-w64's `ctype.c` and `wchar.h` are respectively missing declaration of
`_isblank_l` and `_iswblank_l` symbols.
- Kirill Makurin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/
seems strange
to me.
None of source files use `ftime`. There are some tests in `tests_pthread`
subdirectory that use it, but the explicitly include `sys/timeb.h`.
- Kirill Makurin
From 8845189f7a9a0943d2eeea437a723c64da0f Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Sun, 16 Feb 2025
Here's the updated patch. I also used `$(INSTALL_DATA)` instead of `$(LN_S)`
which I think makes more sense.
- Kirill Makurin
From: LIU Hao
Sent: Sunday, February 16, 2025 8:46 PM
To: Kirill Makurin; mingw-w64-public@lists.sourceforge.net
Subject: Re: [Ming
What do you think about usage of `$(LN_S)` in install-exec-hook? I'm not fan of
it because if the library will be built from Cygwin environment it'll create
actual symbolic links which cannot be read by native applications.
- Kirill Makurin
From: LI
If you're good with that patch, I would like to update it to also remove lines
in `configure.ac` which define `COPY_STATIC` and `COPY_SHARED` Automake
conditionals. Let me know what you decide.
- Kirill Makurin
From: Kirill Makurin
Sent: Sunday, Februa
It slipped my mind back then that we can source .la files to get the variables.
I attached modified patch.
The only issue that will remain is silly libtool behavior I described. But I
think it should be fixed in libtool, not by copying the DLL.
- Kirill Makurin
also think to write CMake infrastructure for it, and I want to upload it with a
copy of winpthreads to GitHub. I think it is a much better way to build
winpthreads with MSVC.
Maybe it would even worth to remove support for MSVC tools from winpthreads'
`configure.ac` and `Makefile.am`
pthread_compat.h and use `WINPTHREAD_API`
instead.
Remove duplicated code from pthread.h. It contains verbatim code from sched.h.
Simply include sched.h.
- Kirill Makurin
From 63bc936b8cf13ee302cc4be47f1bb10e7e5a38c2 Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Mon, 10 Feb 2025 17:14:48 +0900
Subject
dependency on winpthreads.la in pthread.la.
I tried to experiment with libtool's --mode=execute hoping it would substitute
.la with a library filename, but --mode=execute works only with executables.
- Kirill Makurin
From: LIU Hao
Sent: Sunday, February 9, 2025 8:
a and libpthread.dll.a so winpthreads can be linked with
usual `-lpthread`.
Any ideas?
- Kirill Makurin
From: LIU Hao
Sent: Sunday, February 9, 2025 6:58 PM
To: Kirill Makurin; mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] make sure WINPTHREAD_A
You make a good point here.
Move both guarded declaration of `clockid_t` and definition of `WINPTHREAD_API
` to pthread_compat.h and include it from both pthread.h and pthread_time.h.
How does this look?
- Kirill Makurin
From: LIU Hao
Sent: Sunday, February 9
See attached patch.
- Kirill Makurin
From 87951029ce19f763ebf28262bf0bb3a48fbed0c2 Mon Sep 17 00:00:00 2001
From: Kirill Makurin
Date: Sat, 8 Feb 2025 01:45:40 +0900
Subject: [PATCH] winpthreads: make sure WINPTHREAD_API is correctly defined in
pthread_time.h
When building with MSVC
public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] winpthreads and MSVC
On 1/30/25 3:02 AM, Kirill Makurin wrote:
> Yes, no problem.
>
> I also had a patch for Makefile.am which tried to solve the alias issue by
> copying `[lib]winpthreads[.dll].{lib|a}` as `[lib]pthread[.dll].
I think `"pthread_time.h"` makes more sense when including headers from the
source tree?
From: LIU Hao
Sent: Friday, January 31, 2025 3:57 PM
To: Kirill Makurin; mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] winpthreads and MS
using `clock_gettime` is that
if it somehow breaks, it will also make this test to fail.
From: LIU Hao
Sent: Friday, January 31, 2025 3:07 PM
To: mingw-w64-public@lists.sourceforge.net; Jonathan Yong; Kirill Makurin
Subject: Re: [Mingw-w64-public] winpthreads and MSVC
在 2025-
:58 PM, Kirill Makurin wrote:
> Hi,
>
> I was writing to the list a few months ago regarding building of winpthreads
> with MSVC tools. I also sent a few patches back then, none of which were
> pushed. The first two patches were fixing a syntax error in `src/thread.h`
> and linking
as a subproject, which will allow projects to
use POSIX threads even when building with MSVC.
- Kirill Makurin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
```
_access(filename, X_OK)
```
will always return -1 and set errno to EINVAL.
Windows does not use execution permissions for files. Maybe it would make sense
to define X_OK to the same value as R_OK?
- Kirill Makurin
___
Mingw-w64-public mailing list
Mingw
read.la to construct alias filenames
seems convenient, but it probably has to be tested every time new version of
libtool is used.
- Kirill Makurin
From: JonY via Mingw-w64-public
Sent: Wednesday, November 13, 2024 9:22 AM
To: mingw-w64-public@lists.sourceforge.net
t will create actual symbolic links, but native
(non-cygwin/msys2) programs cannot read them.
- Kirill Makurin
From: Antonin Décimo
Sent: Thursday, November 7, 2024 8:36 PM
To: mingw-w64-public@lists.sourceforge.net
; Kirill Makurin
Subject: Re: [Mingw-w64-public]
ch
may fail if CC has value like "cl.exe -nologo -std:c11". Try to compile and
check whether macro _MSC_VER is defined may be more robust. I may write a patch
for this as well.
*
Kirill Makurin
From 2d0ef83e3981ebf91fc81f9c48018d2a7fa4fe78 Mon Sep 17 00:00:00 2001
From: Kirill M
69 matches
Mail list logo
