On 7 June 2014 17:00, Stefan Weil <address@hidden> wrote:
Am 07.06.2014 16:58, schrieb Peter Maydell:
It's clearly something to do with it getting confused by the type name,
because you can suppress the warning by just changing it so it has
an "_t" suffix, for instance. In particular notice that the set of allowed
type names constructed by the build_types() subroutine is extremely
limited: it looks to me as if the script makes assumptions based on
kernel style (where 'struct foo' is preferred over a typedef and plain
'foo') that allow it to assume that if it's not one of a very few allowed
formats then it's not a type name.
Yes, but that's only part of the story. checkpatch.pl contains some
special handling for the standard C data types and also knows some Linux
data type patterns. It also handles the above case correctly in most
circumstances because there is special code for "*" used in function
argument lists.
Interesting. There are obviously multiple situations where it
fails in this way for different reasons. This is the case I saw yesterday:
@@ -125,19 +125,20 @@ static TCGRegSet tcg_target_available_regs[2];
static TCGRegSet tcg_target_call_clobber_regs;
#if TCG_TARGET_INSN_UNIT_SIZE == 1
-static inline void tcg_out8(TCGContext *s, uint8_t v)
+static __attribute__((unused)) inline void tcg_out8(TCGContext *s, uint8_t v)
{
*s->code_ptr++ = v;
}
No macros or previous context for it to get confused by.
Saying "TCGContext_t" instead silences the warning.