[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cascaded casts
From: |
John Darrington |
Subject: |
Re: Cascaded casts |
Date: |
Sun, 30 Aug 2020 08:06:28 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Tue, Aug 25, 2020 at 07:56:39PM +0200, Friedrich Beckmann wrote:
For i386 there are two more.
Maybe Ben can have a look at the enum casts:
https://git.savannah.gnu.org/cgit/pspp.git/commit/?id=5b2ed095a8aaa98adaea4922855edcbfb619c728
As far as I understood the code this are intentional ???extensions???:
https://git.savannah.gnu.org/cgit/pspp.git/tree/src/language/data-io/placement-parser.c?id=5b2ed095a8aaa98adaea4922855edcbfb619c728#n37
An alternative to the function casts for g_list_foreach that I did in the
first place is to create a new function ???free_tree??? with exactly two
parameters which then calls gtk_tree_path_free. That free_tree function is then
used in g_list_foreach. But I found that difficult to read due to the
additional function call level. Therefore I did this cast which relies on this
???undefined??? compiler behaviour. Would you prefer this alternative?
For these g_list_foreach functions, what I suggest is that we define a macro.
For example:
#define STRANGE_CAST(X) ((GFunc) (((void (*) (void))))((X)))
then we can write
g_list_foreach (l, STRANGE_CAST (gtk_tree_path_free), NULL);
instead of
g_list_foreach (l, (GFunc) (void (*)(void)) gtk_tree_path_free, NULL);
When I run configure with CFLAGS=???-Wall -Wextra -Wunused-parameter
-Wsign-compare??? (= full)
then I get the following warnings:
982 sign-compare
I think sign compare we can safely ignore. So far as I'm aware, it can only
ever be a problem if
we get ported to a system which does not use twos' complement arithmetic. I
don't know of any
such systems in the last 40 years.
620 unused-parameter
In Gtk+ there are going to be lots of unused parameters, due to the reliance it
makes on callbacks.
We should ignore this in the gui code.
18 deprecated-declarations
These we should keep, and not suppress. Eventually we're going to have to fix
them.
15 unused-value
6 unused-variable
2 pointer-arith
2 pointer-sign
1 type-limits
1646 Total
These we should perhaps look at on a case-by-case basis. If the compiler is
warning us for
a good reason, then we shouldn't suppress it.
This includes the perl module and the gl functions which are both compiled
without any warning setup per default. With current default compiler setup we
have
18 deprecated-declarations
2 pointer-arith
2 maybe-uninitialized
1 return-local-addr
23 Total
With Gnulib we have to assume that the Gnulib developers know what they're
doing. With the perl module,
there are some issues relating to i18n which these warnings are indicating.
The warnings should stay
until they have been fixed properly.