Re: [Qemu-devel] checkpatch.pl question

[Paolo Bonzini <pbonzini@redhat.com>]

Il 07/06/2014 18:27, Peter Maydell ha scritto:
> On 7 June 2014 17:00, Stefan Weil <sw@weilnetz.de> 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.

Given QEMU's coding style, any camelcase identifier (or equivalently and 
identifier containing an uppercase and a lowercase letter) could be 
considered a type.

Paolo