[Xfce4-commits] r29924 - in xfce4-dev-tools/trunk: . m4macros

[Brian J. Tarricone]

On 05/20/2009 12:02 AM, Ali Abdallah wrote:

> -Wdisabled-optimization: with this gcc will emit a warning if it cannot
> optimize a piece code, because it is too complex or something, so one
> can try to improve/simplify the code.

Yeah, maybe.  I don't see this as terribly useful, but it probably can't 
hurt.  Well, I guess it could... it might break a -Werror build, even 
when you don't care to 'fix' the code (cuz, really, there's nothing 
actually wrong with it).

> -Wwrite-strings: warning about writing on string constants.

I considered this one, but unfortunately there are many functions (in 
glib, even, I believe) that take (char *) that really should take (const 
char *) where it doesn't actually modify the value and it's common to 
pass a string literal.  It *would* be really great to use this, but it 
would cause too many spurious warnings.  Doing ugly things like 
foot((char *)"bar"); to suppress the warning is just lame.

> -Wunreachable-code: gcc will emit a warning if it thinks that the code
> will never be executed because of a condition that will never be
> satisfied, sometimes it produces wrong warnings and one can discard them
> safely after examining the code, but sometimes yes it tells you about a
> code that will really never be executed (unless the CPU logical unit is
> broken :) ).

Nope, this is a bad idea.  Macros like g_return_if_reached() and 
g_assert_if_reached() could trigger this.

> -Winline, if a function cannot be inlined, but well we never use inline
> functions in Xfce.

Well, some of us do...  I considered this one, but it's too variable and 
unknown as to whether or not a function will inline properly, and if you 
get this warning, it may not be remotely clear how to "fix" it (aside 
from just removing the 'inline' keyword).  Having said that, gcc usually 
does a much better job of deciding when to inline a function than people 
do, so often it's better to just not use the 'inline' keyword.

These are nice in theory, but remember that --enable-debug=full also 
adds -Werror to the list; personally I will never (unless I forget) 
check in code that doesn't compile with -Werror (on my machine at 
least).  Adding in extra -W options is nice when they provide a clear 
benefit and aren't likely to throw spurious warnings, but when it's not 
really clear why code might cause a warning (like for 
-Wdisabled-optimization and -Winline), or when existing code can't help 
but cause the warnings (like -Wunreachable-code or -Wwrite-strings), 
they become a lot less useful.

Thanks for looking into these, though...  if there are others that look 
useful but low-risk, I'd certainly consider putting them in.

	-brian