On 18 March 2015 at 19:22, John Snow <js...@redhat.com> wrote: > There's one case of error here that's interesting that ccache unearths: > > we use a gnu extension to give return values to compound statement blocks, > then wrap these blocks into macros as if they were functions. > > The practical outcome here is that these blocks have return codes that we > often don't check, so clang will spit out "unused value" warnings if we > compile these after preprocessing, like ccache will tend to do. > > This warning is potentially valid: if these calls can fail, we should > probably either be asserting that a failure did not occur OR we should > switch to a variant without a return code, if failure is impossible in these > locations. > > An example of this is in linux-user/elfload.c where we define the > NEW_AUX_ENT() macro which in turn uses the put_user_ual(val, sp) macro. When > this is expanded, it turns into a compound statement where we discard the > expression result, so clang whines. > > Of course, this all goes away if you disable ccache, but is it worth > adjusting this particular usage anyway?
I agree that ideally we wouldn't do that, but why is this only visible via ccache? If ccache creates warnings that aren't visible when directly running the c compiler then that's a bug in ccache even if the warnings are in theory interesting. -- PMM
