GNOME Bugzilla – Bug 725995
Vala outputs code that falls afoul of -Werror=nonliteral-format
Last modified: 2016-11-12 08:12:58 UTC
-Werror=non-literal format is in gnome-common, so a lot of gnome modules are using it. On clang, this means that this code fails to build (due to use of a non-literal format string): _tmp13_ = stdout; _tmp14_ = _ ("Run '%s --help' to see a full list of available command line options."); _tmp15_ = arguments; _tmp15__length1 = arguments_length1; _tmp16_ = _tmp15_[0]; fprintf (_tmp13_, _tmp14_, _tmp16_); (see cheese bug 725994). I'm not sure why the tmp variables are used, but in cases like this they are causing problems. Maybe it makes sense to 'try harder' here to eliminate them?
FYI: we just hit this problem in gnome-terminal: bug 730532 comment 9. Are there any short-term plans to fix this in vala, or is there any known workaround for apps?
(In reply to comment #0) > I'm not sure why the tmp variables are used, but in cases like this they are > causing problems. Maybe it makes sense to 'try harder' here to eliminate them? I don't think it's possible to do in non-hacky way without breaking backward compatibility. Consider: stderr.printf(_("xxx %s"), foo()); Currently the _("xxx %s") in Vala is always run before foo() while if it would be put directly it would be run after (if foo() still emits the temporary variables) or in undefined order (if foo() was put in argument list). For all Vala knows the foo() might change the user locale. While it can be argued that foo() should not change locale in general it would mean that printf and _ are special-cased in argument generation as there might be more legitimate code which depends on Vala left-to-right evaluation and need to preserve the ordering. > Are there any short-term plans to fix this in vala, or is there any known > workaround for apps? Compile vala-generated code with -w -Werror=none flags. The code is perfectly legal according to the standard - it's just that it's written in a way that if it was written by human it might indicate that returned value is unsafe. For all clang knows _ might read the data from network and user might trick it by preparing input in a way that cause buffer overflow. We know it's not a case here so the warning can be safely ignored. (While I'm not Vala dev - and AFAIK at least some of them disagree - my believe is that Vala codegen is sufficiently complicated to not bother with producing warning-free code. The warnings are type of lint and are very useful for programmers for avoiding the errors and notifying about potentially dangerous constructs while all Vala would do is to silence them. At the end of the day it does not make sense to run lint on assembly produced by C compiler and get warnings about possibly uninitialized registers or using the same memory on stack for integer and pointer, because in C code the variable ranges does not overlap. In similar way the Vala codegen should strive to produce legal, bug-free C code in simplest way possible instead of producing simplest, bug-free and warning-free C code in not necessary simple way.).
(In reply to comment #2) > Compile vala-generated code with -w -Werror=none flags. Thanks very much for your explanation, it makes sense to me. Is there any way Vala could ship some magic that causes automake-generated Makefiles to automatically insert these flags into rules that invoke gcc on the vala-generated output? Ideally (e.g. if valac was a wrapper in front of gcc, rather than a separate step in the toolchain) I would argue that it's vala's responsibility to adjust CFLAGS into something that makes sense. It shouldn't be the caller taking care of this. I'm not familiar enough with automake to tell if it's technically possible.
(In reply to comment #3) > (In reply to comment #2) > > > Compile vala-generated code with -w -Werror=none flags. > > Thanks very much for your explanation, it makes sense to me. > > Is there any way Vala could ship some magic that causes automake-generated > Makefiles to automatically insert these flags into rules that invoke gcc on the > vala-generated output? > I haven't look into details but no AFAIK. The vala just compiles to C and gcc is run by automake. The gcc does not have the warnings promoted to errors by default (or even emitted all possible warnings) because even for 'real' C programs warnings are moving target (newer compilers -> better heuristic -> more true warnings and less false positives[1]) - they have been explicitly override in gnome-common. In libgee which does not use gnome-common it it's rarely a problem (I believe I had in total 1 bug from packager who insisted on passing -Werror as matter of distro policy) - especially after just putting -w in CFLAGS. You can override on per Makefile or per package basis (the former is via AM_CFLAGS IIRC while for latter see libgee makefiles). I'm not sure who maintains the Vala in automake but it would be possible to do it semi-automatically - if file was from Vala pass -w at the end. I don't think it's a good idea to override explicit power-user requests as a matter of policy but it's probably the same 'giving up' as I've done in case of libgee. [1] If they are enabled also in release I'd call the practice questionable for that reason - gcc 4.9 can compile say gnome-terminal but gcc 4.10 will have better warnings, which will be promoted to errors making gnome-terminal not compilable against gcc 4.10. (On the other hand hardcoded -Werror -Wall -Wextra makes perfect sense for builds from git in C programs). PS. Sorry for warning rants. I'm all for code that compiles without warnings but this IMHO only applies to the first compiler in chain.
Thanks very much for your detailed response again :) We already had a couple of -Wno... flags for gnome-terminal vala code, I've just added one more now, but next time something fails I guess we'll go with the ultimate -Werror=none.
*** This bug has been marked as a duplicate of bug 769229 ***