On 09.06.2023 12:12, Michal Orzel wrote:
>
>
> On 09/06/2023 11:47, Jan Beulich wrote:
>>
>>
>> On 09.06.2023 11:36, Michal Orzel wrote:
>>> On 09/06/2023 10:54, Jan Beulich wrote:
>>>> On 08.06.2023 14:18, Roberto Bagnara wrote:
>>>>> On 07/06/23 09:39, Jan Beulich wrote:
>>>>>> On 05.06.2023 15:26, Roberto Bagnara wrote:
>>>>>>> On 05/06/23 11:28, Jan Beulich wrote:
>>>>>>>> On 05.06.2023 07:28, Roberto Bagnara wrote:
>>>>>>>>> U6) Empty declarations.
>>>>>>>
>>>>>>> Examples:
>>>>>>>
>>>>>>> xen/arch/arm/arm64/lib/find_next_bit.c:57.29:
>>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999
>>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is
>>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>>
>>>>>>> xen/arch/arm/arm64/lib/find_next_bit.c:103.34:
>>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999
>>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is
>>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>
>>>>>> Looks like these could be taken care of by finally purging our
>>>>>> EXPORT_SYMBOL() stub.
>>>>>>
>>>>>>> xen/arch/arm/include/asm/vreg.h:143.26:
>>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999
>>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is
>>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>>
>>>>>>> xen/arch/arm/include/asm/vreg.h:144.26:
>>>>>>> empty declaration (ill-formed for the C99 standard, ISO/IEC 9899:1999
>>>>>>> Section 6.7: "An empty declaration." [STD.emptdecl]). Tool used is
>>>>>>> `/usr/bin/aarch64-linux-gnu-gcc-12'
>>>>>>
>>>>>> I'm having trouble spotting anything suspicious there.
>>>>>
>>>>> The macro expands to definitions of inline functions
>>>>> and after the macro invocation there is a ";".
>>>>>
>>>>> The preprocessed code is then:
>>>>>
>>>>> static inline void foo() { ... }
>>>>> ;
>>>>>
>>>>> where the final ";" is an empty declaration not allowed by
>>>>> the C99 language standard.
>>>>
>>>> Oh, I see.
>>>>
>>>>> Removing the ";" after the macro invocation is a possible solution,
>>>>> but other possibilities exist if this is strongly unwanted.
>>>>
>>>> We have other macros to instantiate functions, and there no stray
>>>> semicolons are used. I think this wants doing the same way here, but it
>>>> being Arm code the ultimate say is with the Arm maintainers.
>>> Apart from vreg.h the same applies to TLB_HELPER of arm32/arm64.
>>> I think also TYPE_SAFE would want to be fixed.
>>
>> Indeed. For this last one I wonder though whether it wouldn't be better
>> to continue to permit (really: require) the semicolon at the use sites,
>> by putting the typedef-s last and omitting the semicolon in the macro
>> definitions.
> This would be an error I think since the functions are defined using this type
> so it must be defined first. Unless there is a way to forward typedef.
Well, I didn't make the suggestion without first checking whether that
would (likely) be possible.
> All in all,
> removing semicolon at use sites is simpler.
Simpler - yes. But syntax-wise I think it is best if, except in special
cases, kind-of-statements and kind-of-declarations ended with a semicolon.
Special cases would be in particular ones where macro definition and
macro use are next to one another.
Jan
