LIU Hao wrote:
在 2024-02-19 15:56, Christian Franke 写道:
The __MINGW_FORTIFY_LEVEL set in _mingw_mac.h has no effect if a
program including Win32 API headers like windows.h is compiled for
Cygwin (same applies possibly to MSYS2). The __MINGW_FORTIFY_LEVEL
only affects Libc includes which are
LIU Hao wrote:
在 2024-02-19 02:31, Christian Franke 写道:
Cygwin's cygport now defaults to _FORTIFY_SOURCE=3 but the stable
Cygwin gcc is still 11.4.0 which does not support it. If Cygwin
programs include windows.h, this results in bogus warnings or broken
builds if -Werror is set. The att
From 8af250ab394bc5785e4c53227cadc26370875956 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Sun, 18 Feb 2024 19:24:01 +0100
Subject: [PATCH] Ignore _FORTIFY_SOURCE if __MINGW32__ is not defined
This prevents bogus warnings or build aborts (-Werror) if Windows
includes are used on Cygwin.
Signe
LIU Hao wrote:
在 2023/10/23 15:50, Jonathan Schleifer 写道:
Could you please explain why a compile time check would be preferable
over a runtime check here? The cost of this runtime check should not
be noticeable, most likely not even measurable. Doing runtime check
seems extremely common on Win
LIU Hao wrote:
在 2023/7/18 21:41, Christian Franke 写道:
AFAICS various of the Annex K *_s() functions are long standing parts
of MSVCRT/UCRT and have a compatible signature.
The patch was not intended to be a starting point for adding any of
the missing functions. It only should fix this
LIU Hao wrote:
在 2023/7/16 00:59, Christian Franke 写道:
According to https://en.cppreference.com/w/c/chrono/localtime C11
added optional gmtime_s() and localtime_s() which conflict with the
long standing MSVCRT/UCRT variants. I have no idea why they did this
(C23 finally adds the traditional
fbcdb908526f31c8872f5e639af87a26187eab10 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Sat, 15 Jul 2023 18:42:42 +0200
Subject: [PATCH] headers: Add C11 variants of gmtime_s and localtime_s
Enable these only if __STDC_WANT_LIB_EXT1__ is defined to nonzero.
Then define __STDC_LIB_EXT1__ to indicate
Martin Storsjö wrote:
On Fri, 17 Feb 2023, Christian Franke wrote:
When compiling this on MSYS2 UCRT64 with current
mingw-w64-ucrt-x86_64-gcc 12.2.0-10, gcc and g++ results differ:
#include
#include
#if !(defined(_UCRT) && !__USE_MINGW_ANSI_STDIO)
#warning unexpected configuratio
When compiling this on MSYS2 UCRT64 with current
mingw-w64-ucrt-x86_64-gcc 12.2.0-10, gcc and g++ results differ:
#include
#include
#if !(defined(_UCRT) && !__USE_MINGW_ANSI_STDIO)
#warning unexpected configuration
#endif
void f(size_t s, uint64_t u)
{
// gcc: No warning
// g++: "unknown
This check in line 282 of inttypes.h is always false because
__USE_MINGW_ANSI_STDIO is always defined to 0 or 1 in _mingw.h:
#if (defined(__CRTDLL__) || __MSVCRT_VERSION__ < 0x200) &&
!defined(__USE_MINGW_ANSI_STDIO)
No patch included because I don't know whether this section is still
needed
gards,
Christian
From 87d0961909d096a0fb23d24abeddc0cd7e83fdab Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Tue, 14 Feb 2023 13:00:05 +0100
Subject: [PATCH] headers: Always warn if gets() is used
Signed-off-by: Christian Franke
---
mingw-w64-headers/crt/stdio.h | 3 ++-
1 file changed, 2 inser
LIU Hao wrote:
Side note: I am a bit curious how this function is supposed to be
useful. Generally speaking `get()` should never be used.
__gets_chk() may (only) be useful to fortify very old code.
From the C/C++ standards point of view, the gets() prototype should be
disabled if C11 or C++
intentional, I would suggest to apply this patch.
Upstream still provides this function:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libssp/gets-chk.c
--
Regards,
Christian
From 8d0ef5463e1695a40aeaef948787a648a496f267 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Sun, 12 Feb 2023 16:05:07
Still missing after this patch: [v]s[n]wprintf() for UCRT and MSVCRT.
--
Regards,
Christian
From 7d04fa1ddd86a0d46ec3222a1e09455e4b8dd85a Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Sun, 12 Feb 2023 15:24:46 +0100
Subject: [PATCH] headers: _FORTIFY_SOURCE: Add [v]s[n]printf() for
From 92743420b3ad6515fb98d71f8ef929aad8343e84 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Wed, 8 Feb 2023 22:09:32 +0100
Subject: [PATCH] headers: _FORTIFY_SOURCE: Use __has_builtin() instead of
version check
Check for support of __builtin_dynamic_object_size() and
__builtin_va_arg_pack() with __has_bu
LIU Hao wrote:
在 2023-02-04 20:51, Théo Cavignac 写道:
Sorry, I misclicked and sent an half written mail.
So as I tried to expose, I am using MinGW with following configuration:
This looks like a GCC issue. Reported here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108673
Workaround: -f
7 00:00:00 2001
From: Christian Franke
Date: Fri, 3 Feb 2023 19:33:44 +0100
Subject: [PATCH] headers: _FORTIFY_SOURCE: Enhance missing open() argument
warning
Also warn if open() flags are non-const but _O_CREAT is set
unconditionally.
Signed-off-by: Christian Franke
---
mingw-w64-headers/cr
LIU Hao wrote:
在 2023/2/2 06:41, Christian Franke 写道:
This patch allows to use _FORTIFY_SOURCE=3 which is also supported by
GLIBC headers.
Thanks. This patch looks good to me. Pushed now.
BTW does clang support this as well? I suspect we should add a check
for clang too
Good point
= malloc(42);
__memcpy_chk(p1, s, n, 42);
p2 = malloc(sz);
__memcpy_chk(p2, s, n, sz);
}
--
Regards,
Christian
From d6605cc07c325867f3099f13639d11f7692b1ced Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Wed, 1 Feb 2023 23:10:33 +0100
Subject: [PATCH] headers: Add support for
LIU Hao wrote:
These patches address the issue mentioned earlier.
Regarding patch 0001-...:
Attached is a possibly complete list of duplicates within each def file
from lib-common:
Generated with:
for f in *.def*; do
sed 's,;.*$,,;/^$/d;/^#/d;' "$f" | sort | uniq -d | sed "s,^,$f: ,"
do
LIU Hao wrote:
在 2022-04-28 23:55, Corinna Vinschen 写道:
But then again, this seems to be a bug in the w32api import libs,
rather than a problem with the toolchain, no?
Yes; and similar issues did happen some times before, such as in these
commits:
* 68d0e7d551d2e2a5b8a15bdca3f8d15fc097
Hi Corinna,
Corinna Vinschen wrote:
On Apr 28 17:34, Corinna Vinschen wrote:
Hi Christian,
On Apr 28 17:24, Christian Franke wrote:
For some unknown reason, certain functions from advapi32.dll are now also
exported by the kernel32.dll of recent Windows versions. To provide backward
For some unknown reason, certain functions from advapi32.dll are now
also exported by the kernel32.dll of recent Windows versions. To provide
backward compatibility, -ladvapi32 must occur before -lkernel32 in the
linker command, but this is not the case by default:
Testcase with current packag
... in particular BusTypeNvme.
From 26b61d33a96e4cede27e2ebf8e3e1b535df7b9f5 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Fri, 14 May 2021 14:12:05 +0200
Subject: [PATCH] headers: Add more constants to STORAGE_BUS_TYPE.
Signed-off-by: Christian Franke
---
mingw-w64-headers/include
Use case of Compact OS compression:
https://sourceware.org/pipermail/cygwin-apps/2021-May/041225.html
From bfc194b71cd3f490255f3955436eb9e636ce3d33 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Wed, 12 May 2021 18:09:33 +0200
Subject: [PATCH] headers: Add definitions for Compact OS
This patch makes the precision of CLOCK_REALTIME consistent with new
'gettimeofday()' and provides the old behavior as CLOCK_REALTIME_COARSE.
CLOCK_REALTIME_COARSE is not part of POSIX, but available in Linux since
2009 and in Cygwin since 2018.
--
Best regards,
Christian Fr
Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Tue, 4 May 2021 11:52:02 +0200
Subject: [PATCH] crt: Increase precision of gettimeofday() if possible.
Use GetSystemTimePreciseAsFileTime() if available.
Signed-off-by: Christian Franke
---
mingw-w64-crt/misc/gettimeofday.c | 19 ++
Martin Storsjö wrote:
On Mon, 3 May 2021, Martin Storsjö wrote:
On Mon, 3 May 2021, Christian Franke wrote:
Liu Hao wrote:
在 2021-05-03 14:49, Martin Storsjö 写道:
Just for the record - I wouldn't mind applying the patch or
something like it. I agree with the arguments that it wou
ly need to provide such precision.
Oh fair enough, if you would like it, I don't mind applying it either.
Attached is a new patch with '_Atomic' and 'intptr_t' as requested.
--
Best regards,
Christian Franke
From a8d782e5a51deba50f0746080c4f34bb15caf7a7 Mon Sep 17 00:00:0
Liu Hao wrote:
在 2021-04-29 03:34, Christian Franke 写道:
BTW.2: The *ftime*() functions from newer versions of MSVC CRT also use
GetSystemTimePreciseAsFileTime() if available.
UCRTBASE.DLL still uses `GetSystemTimeAsFileTime()`.
A test program build with VS2019 and estimation of the
Vincent Torri wrote:
On Wed, Apr 28, 2021 at 9:35 PM Christian Franke
<...> wrote:
BTW.1: Hack:
Do this once in the program
#ifdef _WIN32
timeBeginPeriod(1);
https://docs.microsoft.com/fr-fr/windows/win32/api/timeapi/nf-timeapi-timebeginperiod?redirectedfrom=MSDN
"Setti
Corinna Vinschen wrote:
On Apr 26 20:00, Christian Franke wrote:
System calls and resolutions of C++11 clocks:
Mingw-w64 MSVC16 Cygwin
system_clock::now() 1 2 2
steady_clock::now() 1 3 3
Liu Hao wrote:
在 4/27/21 2:00 AM, Christian Franke 写道:
Which complexity do you mean - the extra cost of the system call or
the extra 15 lines of code?
It's actually both.
Wall clocks are not meant to be steady, because they are free to jump
back and forth due to NTP synchronization
Liu Hao wrote:
在 2021-04-22 20:35, Christian Franke 写道:
This patch significantly increases the precision of gettimeofday() on
Windows 8 or later. It is then similar to Cygwin or Linux.
It also affects C++11 std::chrono:*_clock as
_GLIBCXX_USE_GETTIMEOFDAY is defined but not
GetSystemTimeAsFileTime(): <3ns
--
Regards,
Christian
From f3366a524643067b7adb0d535c38bb106bda42e2 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Thu, 22 Apr 2021 13:47:30 +0200
Subject: [PATCH] crt: Increase precision of gettimeofday() if possible.
Use GetSystemTimePreciseAsFileTime() if availa
cted.
From c853a56065835e055adb72f7288da8fa8eb53cf7 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Wed, 9 Oct 2019 21:57:50 +0200
Subject: [PATCH 2/2] headers: _FORTIFY_SOURCE: Limit level for functions which
work on raw memory.
Allow mem*() and *read() to use the memory up to the end of
This patch has no effect on generated code. See [PATCH 2/2] for use case.
From e7a3778a0db64fb6b9ba0bac8a225a73f45e9529 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Wed, 9 Oct 2019 21:28:17 +0200
Subject: [PATCH 1/2] headers: _FORTIFY_SOURCE: Allow to limit level for
individual
ot yet sure how to handle the _O_CREAT constant from fcntl.h:
directly use 0x0100 or define _O_CREAT in io.h. The patch uses the latter.
--
Christian
From b28b3f65eb8cb5d0412737493bd7e1f26a4c24ad Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Sun, 29 Sep 2019 15:45:50 +0200
Subject:
Martin Storsjö wrote:
On Fri, 27 Sep 2019, Martin Storsjö wrote:
On Fri, 27 Sep 2019, Christian Franke wrote:
Martin Storsjö wrote:
...
Sorry, I forgot about this after the other issue with gnu_inline
was sorted out.
I guess this patch should be ok, as I presume it's a s
Martin Storsjö wrote:
On Fri, 27 Sep 2019, Christian Franke wrote:
Christian Franke wrote:
Martin Storsjö wrote:
On Fri, 13 Sep 2019, Christian Franke wrote:
...
__attribute__((__format__ (ms_printf, 3, 4)))
__MINGW_ATTRIB_NONNULL(3)
-int snprintf (char * __restrict__ __stream, size_t __n
Christian Franke wrote:
Martin Storsjö wrote:
On Fri, 13 Sep 2019, Christian Franke wrote:
...
__attribute__((__format__ (ms_printf, 3, 4)))
__MINGW_ATTRIB_NONNULL(3)
-int snprintf (char * __restrict__ __stream, size_t __n, const char
* __restrict__ __format, ...)
+int snprintf (char
Martin Storsjö wrote:
On Fri, 13 Sep 2019, Christian Franke wrote:
...
Ok, now with this patch I see the reason for patch 1/2.
Having to manually disable this on errors doesn't feel ideal
I decided to enable the functions by default as the usage of s*printf()
addresses is IMO
Martin Storsjö wrote:
On Fri, 13 Sep 2019, Christian Franke wrote:
...
__attribute__((__format__ (ms_printf, 3, 4))) __MINGW_ATTRIB_NONNULL(3)
-int snprintf (char * __restrict__ __stream, size_t __n, const char *
__restrict__ __format, ...)
+int snprintf (char *__stream, size_t __n, const
Liu Hao wrote:
...
There is something worse: As these wrappers uses
`__builtin_va_arg_pack()` they MUST always be emitted inline, not just
be declared inline. If inline is not possible, the inline definition
cannot be used, which is exactly the `__gnu_inline__` behavior.
Yeah, the bad news is t
Martin Storsjö wrote:
On Tue, 10 Sep 2019, Christian Franke wrote:
AFAICS most of the *printf() and *scanf() inline wrappers are not (or
no longer) needed. Prototypes with __asm__() could be used instead.
This patch removes a subset of these functions. As a side effect, It
also fixes a
...
From 26774c66ae0298e1640e276f8fd50edc39e43874 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Fri, 13 Sep 2019 21:39:59 +0200
Subject: [PATCH 2/2] headers: _FORTIFY_SOURCE: Allow to disable usage of
__builtin_va_arg_pack().
_FORTIFY_VA_ARG=0 disables inline functions with
...
From 3e729fff4a79bf4887ef7df94bd4502aa22d9852 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Fri, 13 Sep 2019 21:20:19 +0200
Subject: [PATCH 1/2] headers: _FORTIFY_SOURCE: Use __builtin_va_arg_pack()
only if needed.
GCC may report an error if the address of an inline function with
Martin Storsjö wrote:
On Sat, 7 Sep 2019, Christian Franke wrote:
Martin Storsjö wrote:
On Wed, 4 Sep 2019, Liu Hao wrote:
在 2019/9/4 4:09, Martin Storsjö 写道:
In this case, it doesn't get emitted as .linkonce discard - I'm
not sure
exactly what's going on in this combinatio
12c43914d2d0086bc182e5ac23485157cd85912f Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Tue, 10 Sep 2019 23:23:31 +0200
Subject: [PATCH] headers: Remove __USE_MINGW_ANSI_STDIO *printf() inline
functions.
Redirect *printf() to __mingw_*printf() functions via __asm__() prototypes.
Declare _FORTIFY_SOURCE
Martin Storsjö wrote:
On Wed, 4 Sep 2019, Liu Hao wrote:
在 2019/9/4 4:09, Martin Storsjö 写道:
In this case, it doesn't get emitted as .linkonce discard - I'm not
sure
exactly what's going on in this combination, whether it's contradicting
itself in C++ mode, or if it's just a bug.
I could ta
Liu Hao wrote:
...
There is something worse: As these wrappers uses
`__builtin_va_arg_pack()` they MUST always be emitted inline, not just
be declared inline. If inline is not possible, the inline definition
cannot be used, which is exactly the `__gnu_inline__` behavior.
Yeah, the bad news is t
...
From 751bb8a69dc0e9a0ae60854afbef60f3a3c74148 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Wed, 4 Sep 2019 22:53:36 +0200
Subject: [PATCH] header: _FORTIFY_SOURCE: Add _read() and read().
Signed-off-by: Christian Franke
---
mingw-w64-headers/crt/io.h | 20
1
Using original gets() is always unsafe.
From fb71db412b9184cbb84761f4f91ef872d1c42b25 Mon Sep 17 00:00:00 2001
From: Christian Franke
Date: Wed, 4 Sep 2019 22:12:53 +0200
Subject: [PATCH] headers: _FORTIFY_SOURCE: Print warning if original gets() is
called.
Signed-off-by: Christian Franke
Liu Hao wrote:
在 2019/8/28 2:38, Christian Franke 写道:
These warnings are not printed for calls of the v*printf() functions,
only for the non-v variants. Delegating to non-v variants always
requires __builtin_va_arg_pack() which is not used in the existing code.
Adding the pragmas back only
Liu Hao wrote:
在 2019/8/27 5:26, Christian Franke 写道:
I have a couple of questions:
0) What was the purpose of the suppression of `-Wformat-nonliteral`? It
seemed not added in every `v?sn?printf` function.
The new inline sn?printf() functions delegate the call to (non-v)
*_sn?printf
Liu Hao wrote:
...
Thanks for your extensive work. The patch looks mostly good.
Thanks. Meantime I found out that libssp.a actually provides
__mem*_chk() and __str*_chk(), so __builtin___*_chk() could be used
instead of manual checks. This makes string.h straightforward. This also
re-enables
JonY wrote:
On 8/24/19 6:50 PM, Christian Franke wrote:
Hi,
packages from Linux and *BSD distros are often build with
-D_FORTIFY_SOURCE=2 set by default. This enables buffer overflow checks
for functions like strcpy() if buffer size is known at compile time.
Attached is an experimental patch
Hi,
packages from Linux and *BSD distros are often build with
-D_FORTIFY_SOURCE=2 set by default. This enables buffer overflow checks
for functions like strcpy() if buffer size is known at compile time.
Attached is an experimental patch that adds some _FORTIFY_SOURCE support
to Mingw-w64 str
Ahmet Alacadoğan wrote:
> which lib has this reference in mingw w64 i used -lkernel32 -luser32
> -lgdi32 -lwinspool -lshell32 -lcomdlg32 -ladvapi32 -lwindowscodecs
> -ld3d9 -lole32 -loleaut32 -luuid no luck
No lib*.a file from recent (Cygwin) package
mingw64-x86_64-runtime-3.0b_svn5591-1 provid
===
--- ChangeLog (revision 5572)
+++ ChangeLog (working copy)
@@ -0,0 +1,8 @@
+2013-01-30 Christian Franke
+
+ * include/winsvc.h (SERVICE_CONFIG_DELAYED_AUTO_START_INFO): New define
+ for _WIN32_WINNT >= 0x0600. The related struct is already present.
+ (SERVICE_CONFIG_FAILURE_ACTIONS_FLAG): Likew
JonY wrote:
> On 6/18/2012 17:30, Daniel P. Berrange wrote:
>> FYI, you can add "libvirt" (http://libvirt.org) to the list of
>> "Projects successfully using MinGW-w64" on the front page of
>> your website. Thanks for all the MinGW-w64 project's great work
>> & long may it continue.
>>
>> Regards,
On Jan 17, Christian Franke wrote:
>
> Meantime I found an easy workaround: Use C++ linkage for printf
> wrapper functions, see attached patch. Smoke tested with smartmontools
> build.
>
Any comment so far? IMO the patch fixes the problem.
Th
Christian Franke wrote:
Kai Tietz wrote:
The point about C++ is, that we lack a default prototype.
Yes, but if some "int printf(const char *, ...)" prototype is
specified, "__attribute__((format(printf(1,2)))" from builtin info is
always added silently by g++. Eve
Kai Tietz wrote:
> 2012/1/14 Christian Franke:
>> ...
>>
>> The static attribute makes no difference in the C++ case:
>>
>> $ i686-w64-mingw32-g++ -Wformat testfmt2.c
>> testfmt2.c: In function 'int main()':
>> testfmt2.c:18:24: warning: unkn
Christian Franke wrote:
> ...
>
> The bug is likely in g++ itself. If __USE_MINGW_ANSI_STDIO is not set,
> format checking works, but interestingly the prototype does not provide
> a format attribute in this case:
>
> /usr/i686-w64-mingw32/sys-root/mingw/include
JonY wrote:
> On 1/6/2012 04:42, Kai Tietz wrote:
>> 2012/1/5 Christian Franke:
>>> [Originally sent to Cygwin mailing list]
>>>
>>> When printf/scanf functions from MinGW runtime are selected via
>>> __USE_MINGW_ANSI_STDIO, then format string ch
[Originally sent to Cygwin mailing list]
When printf/scanf functions from MinGW runtime are selected via
__USE_MINGW_ANSI_STDIO, then format string checking is broken. This only
affects the C++ compiler:
$ cygcheck -f /usr/bin/i686-w64-mingw32-g++
mingw64-i686-gcc-g++-4.5.3-4
$ cat testfmt.c
#
Kai Tietz wrote:
>
> Hmm, I see the problem here, but I am not sure if it is wise to remove
> the interpretation of the allocation-flag here. This might cause
> differences in behavior.
>
>
AFAICS it doesn't because pstr is not NULL if and only if IS_ALLOC_USED
is set. Pstr is passed as para
Hi,
On Jun 23, 2011, Christian Franke wrote:
> Hi,
>
> thanks for providing mingw-w64.
>
> I found this when I tried to compile smartmontools on Cygwin with
> i686-w64-mingw32 and _USE_MINGW_ANSI_STDIO set:
>
> __mingw_*scanf() always(!) segfaults if a char or string f
Hi,
thanks for providing mingw-w64.
I found this when I tried to compile smartmontools on Cygwin with
i686-w64-mingw32 and _USE_MINGW_ANSI_STDIO set:
__mingw_*scanf() always(!) segfaults if a char or string format (without
malloc option) is used. This is because optimize_alloc() is always
c
70 matches
Mail list logo
