On 18 March 2015 at 19:22, John Snow <address@hidden> 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.