I don't think it's a good idea to just patch how a warning works like that, at least not without a controlling option. But more importantly, if my experience with gcc-patches is anything to go by, expect to be ignored for weeks or months before someone even notices your patch
best regards, Julian On Mon, Sep 23, 2024 at 7:20 PM Hannes Domani via Mingw-w64-public <mingw-w64-public@lists.sourceforge.net> wrote: > > Am Montag, 23. September 2024 um 13:10:23 MESZ hat LIU Hao > <lh_mo...@126.com> Folgendes geschrieben: > > > 在 2024-09-23 18:48, Martin Storsjö 写道: > > > Well, as Liu Hao showed, using (void*) casts can get warned about, if we > > > compile it with all > > > available warning flags. But we don't build mingw-w64-crt that way. > > > > > > Anyway, Liu Hao, you mentioned that you wanted to try to touch up this > > > patch in some way (moving > > > some declaration into a header or similar), feel free to pick it up and > > > do that. Or should we go > > > with it as is, or with a simpler void* which is fine given how > > > mingw-w64-crt is compiled in > > > practice, or intptr_t? > > > > We currently have three options: > > > > 1. Cast the result from `GetProcAddress()` once to `void*`, and let it > > convert > > to the target type implicitly. > > 2. Double-cast the result via `void (*)(void)`. > > 3. Double-cast the result via `intptr_t`. > > > > Jacek is suggesting 1, this patch does 2, and my previous suggestion was 3. > > > > > > My concern is that if today a compiler starts to warn about casts between > > incompatible function > > pointers (which are perfectly okay though), then someday it may start to > > warn about implicit > > conversions between `void*` and function pointers, and we will have to > > patch these casts again. > > > > 2 is the standard solution, but it looks verbose. I suggest that we move > > the `_PVFV` typedef to a > > common header, and reuse it. > > > > 3 is my first suggestion. As with 1 it works in practice, and I believe it > > shouldn't cause warnings > > in reasonable future. > > > Note that it's also possible to patch gcc to ignore function casts > involving FARPROC types, that's what I did in my gcc build: > > > From: Hannes Domani <ssb...@yahoo.de> > Date: Sun, 28 Mar 2021 14:35:56 +0200 > Subject: [PATCH] Don't warn for function casts involving FARPROC > > --- > gcc/c/c-typeck.cc | 5 +++++ > gcc/cp/typeck.cc | 5 +++++ > 2 files changed, 10 insertions(+) > > diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc > index 4567b114734..43c974597ef 100644 > --- a/gcc/c/c-typeck.cc > +++ b/gcc/c/c-typeck.cc > @@ -6131,6 +6131,11 @@ c_safe_function_type_cast_p (tree t1, tree t2) > TYPE_ARG_TYPES (t2) == void_list_node) > return true; > > + /* FARPROC */ > + if (TREE_CODE (TYPE_MAIN_VARIANT (TREE_TYPE (t2))) == INTEGER_TYPE && > + TYPE_ARG_TYPES (t2) == NULL_TREE) > + return true; > + > if (!c_safe_arg_type_equiv_p (TREE_TYPE (t1), TREE_TYPE (t2))) > return false; > > diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc > index 21436f836fa..5b31f8c8b0f 100644 > --- a/gcc/cp/typeck.cc > +++ b/gcc/cp/typeck.cc > @@ -1399,6 +1399,11 @@ cxx_safe_function_type_cast_p (tree t1, tree t2) > TYPE_ARG_TYPES (t2) == void_list_node) > return true; > > + /* FARPROC */ > + if (TREE_CODE (TYPE_MAIN_VARIANT (TREE_TYPE (t2))) == INTEGER_TYPE && > + TYPE_ARG_TYPES (t2) == void_list_node) > + return true; > + > if (!cxx_safe_arg_type_equiv_p (TREE_TYPE (t1), TREE_TYPE (t2))) > return false; > > -- > 2.39.1.windows.1 > > > _______________________________________________ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
