[Top][All Lists]

[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:
     As far as I understood the code this are intentional ???extensions???:
     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 

     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 
     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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]