On 7 June 2014 17:00, Stefan Weil <s...@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.
The debug output shows that here it's failed to parse the
type as a type:
22 > . static __attribute__((unused)) inline void tcg_out8(TCGContext
*s, uint8_t v)
22 >
EEVVVVVVVNNNNNNNNNNNNNNNVVVVVVVVVVVVVVVVTTTTTVVVVVVVVNVVVVVVVVVVVNVCCTTTTTTTTVVV
22 >
________________________________________________________________B______________
(thanks for pointing out that that existed).
-- PMM
