在 2024-04-24 21:43, Antonin Décimo 写道:
This helps when vendoring winpthreads as a subtree.
---
I've just copied the root .gitignore. Works as expected.
mingw-w64-libraries/winpthreads/.gitignore | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 mingw-w64-libr
Hi Martin,
Patches look good to me.
Thanks,
Jacek
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
This redefining of the macro was added in
824ceb1d1265e257d8b85d8e191f4db2a1e7735c, without an explanation
of why that was done.
If we really do need to use a different inline declaration for
these functions, we should use a different macro, so we don't
alter the meaning of the __mingw_ovr define
Hi,
If trying to build libc++'s C++23 std module on top of the mingw
headers, this currently fails for a number of cases where the
std module wants to reexport a number of functions from the
underlying libc. In the case of mingw-w64's headers, many standard
C functions are implemented as inline fu
In the inline form of _snwprintf, we set
_CRT_INTERNAL_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION,
but in the non-inline version, we just called
vsnwprintf, which doesn't set that option.
Instead call __stdio_common_vswprintf directly, with the right
options.
The previous form stemmed from the origi
We should prefer using a macro which doesn't declare functions
as static inline in C++ mode.
This macro was added in bc6a87488995675ae80c312e3585cb1ace739b43,
without an explanation of why it was added.
Signed-off-by: Martin Storsjö
---
I guess it's possible that an explanation for why it was ad
When building the C++23 std modules, at least with libc++, the
C++ module needs to reexport a number of standard C functions.
The regular libc++ headers (the ones used even if not using
C++ modules) do this, essentially:
namespace std {
using ::ctime;
}
Thus reexporting the regul
We already have non-inline versions of these functions; use the
non-inline version consistently, to avoid potential cases of
inconsistency.
Signed-off-by: Martin Storsjö
---
mingw-w64-headers/crt/stdio.h | 22 ++
mingw-w64-headers/crt/wchar.h | 22 ++
2 fi
On Mon, 22 Apr 2024, Pali Rohár wrote:
Add 4 new macros FIXED_SIZE_SYMBOLS, NO_I64_FIXED_SIZE,
NO_FIXED_SIZE_64_ALIAS and NO_TIME_ALIAS to distinguish
between different crt versions.
---
.../def-include/msvcrt-common.def.in | 154 ++
mingw-w64-crt/lib-common/msvcr120_app.
On Mon, 22 Apr 2024, Pali Rohár wrote:
This patch series moves all aliases defined in crtdll.def.in, and
msvcr*.def.in files into one common include file msvcrt-common.def.in.
It reduces duplication of symbol alias definitions by defining symbols
in more declarative manner.
Moving aliases to o
This helps when vendoring winpthreads as a subtree.
---
I've just copied the root .gitignore. Works as expected.
mingw-w64-libraries/winpthreads/.gitignore | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 mingw-w64-libraries/winpthreads/.gitignore
diff --git a/m
在 2024-04-24 20:11, Martin Storsjö 写道:
Agreed, although it's less of a regression if we require windows headers for pthread_cleanup_push
only when built with MSVC, than making it required for everybody, as the library wasn't usable at
all with MSVC until recently.
However, I looked at the outp
On Wed, 24 Apr 2024, LIU Hao wrote:
在 2024-04-24 00:18, Antonin Décimo 写道:
I couldn't find the difference between MemoryBarrier and _ReadWriteBarrier.
Maybe the MemoryBarrier macro is available on more architectures than
_ReadWriteBarrier which is only documented for x86 and x64?
`MemoryBarri
13 matches
Mail list logo
