GNOME Bugzilla – Bug 52026
two helper macros for unused / unitialized variables
Last modified: 2013-02-03 05:54:43 UTC
Given the right flags, gcc will warn about unused variables (either parameters or automatic or static vars) and about uninitialized vars. Sometimes it is intended to do it that way, but you would like to fix the warnings. That can be done easily and without runtime penalty: unused var: (void)var; uninitalized var: (void)&var; Both of course are very non-intuitive. I would propose adding #define g_unused_var(var) ((void)(var)) #define g_uninitialized_var(var) ((void)&(var)) I'm not sure about the names. That way we can as well provide solutions for other compilers, if we get the corresponding information. What do you think?
This of course per GLib policy should not be lower case, but upper case (if added at all): #define G_UNUSED_VAR(var) ((void)(var)) #define G_UNINITIALIZED_VAR(var) ((void)&(var)) or maybe G_VAR_IS_UNUSED and G_VAR_IS_UNINITIALIZED
I don't think the names are quite right G_UNINITIALIZED_VAR() should be something like G_VAR_IS_NOT_UNITIALIZED() or something :-) I don't have a strong feeling about these - it is marginally more efficient to have something like this than the current practice of: gint my_var = 0; /* Quiet GCC */ But I don't know what it should be named exactly, so putting on the future milestone.
For used, note also that GCC has int x __attribute__ ((unused)); Not sure how that relates
Im not convinced this is helpful or necessary code, but this bug should either be implemented or closed.
According to the GCC docs, the unused attribute is for functions. That said, i've seen G_GNUC_UNUSED (which is the GLib version of this attribute) work when used on function arguments. I don't like the fact that it's documented solely as a function attribute, it makes me think that the fact it works for arguments is either a bug or an accident. And besides, it works only on GCC. By example, Perl's headers define a harmless no-op that should be optimized out by any decent compiler. #define PERL_UNUSED_VAR(v) if (0) (v)=(v) This works for unused parameters as well as variables which are declared for you but unused by your code (more an issue when using heavy preprocessing voodoo). Admittedly, it's ugly to litter your code with these statements, but it's also quite explicit. As for whether a macro to hush unused parameter warnings is "helpful or necessary", a lot of people find that using the compiler's warning capabilities to the fullest helps quicken the debugging process when writing new code. Unused parameter warnings cause things to go very badly when using -Werror.
For the record, gcc 4.0 recommends using the unused attribute to turn off warnings on unused functions, parameters, and variables. Glib manual should be updated to reflect that. Unused parameters warnings are typically very hard to shut up, since most of the time the prototype is forced by the caller, e.g. signal handlers, event handlers, etc. In those cases it's quite desirable to be able to shut it up in the code, to see the real warnings. I marginally prefer the approach introduced in this report, since it doesn't clutter with the function definition line, but am already using G_GNUC_UNSED for that. One thing though I'm not sure is where should the G_GNUC_UNUSED macro be used, before the symbol name or after. For gcc it doesn't make any difference. And humm, right, it's specific to gcc, but I can think of definitions for other compilers be added to the same symbol in the future. So, it's at least worth recommending one way over the other. Currently the glib documentation refers user to the gcc manual. As for uninitialized values, I actually like the explicit initialization over fooling the compiler, since it makes the run more deterministic and as a result, isolating bugs easier.
Some points : (1) #define PERL_UNUSED_VAR(v) if (0) (v)=(v) If you do that with a C++ compiler and it doesn't optimize it out, won't it do a self-assignation? (and won't it crash if the self-assignation isn't handled correctly?) (2) I recently enabled more warnings in ekiga's source code when using gcc, and made heavy use of G_GNUC_UNUSED : glib's documentation is indeed more restrictive than gcc's. (3) I put it before everywhere, but I must admit reading "5.25 Attribute Syntax" in gcc's info wasn't very informative... or perhaps I missed it.
(In reply to comment #7) > Some points : > (1) > #define PERL_UNUSED_VAR(v) if (0) (v)=(v) > > If you do that with a C++ compiler and it doesn't optimize it out, won't it do > a self-assignation? > (and won't it crash if the self-assignation isn't handled correctly?) Humm, not sure I understand what you where thinking. Doesn't the "if (0)" mean that the code is never run?
You're definitely right!
Created attachment 156269 [details] [review] Introduce G_UNUSED_VAR I think a macro that doesn't depend on compiler specifics is preferrable where possible and as far as I'm aware, the if (0) approach works fine for both variables and function arguments.
I suggest instead: #ifdef __OPTIMIZE__ #define G_UNUSED_VAR(vvv) G_STMT_START { if (0) (vvv)=(vvv); } G_STMT_END #else #define G_UNUSED_VAR(vvv) G_STMT_START { } G_STMT_END #endif
Wouldn't that mean that I see additional warnings if I disable optimisations?
(In reply to comment #12) > Wouldn't that mean that I see additional warnings if I disable optimisations? It would. But that's better than the code not getting optimized out.