Re: [PATCH][4.15] crypto: adjust rijndaelEncrypt() prototype for gcc11

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.03.2021 12:21, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH][4.15] crypto: adjust rijndaelEncrypt() 
> prototype for gcc11"):
>> On 03.03.2021 20:09, Julien Grall wrote:
>>> On 01/03/2021 07:57, Jan Beulich wrote:
>>>> The upcoming release complains, not entirely unreasonably:
>>>>
>>>> In file included from rijndael.c:33:
>>>> .../xen/include/crypto/rijndael.h:55:53: note: previously declared as 
>>>> 'const unsigned char[]'
>>>>     55 | void    rijndaelEncrypt(const unsigned int [], int, const 
>>>> unsigned char [],
>>>>        |                                                     
>>>> ^~~~~~~~~~~~~~~~~~~~~~
>>>> rijndael.c:865:8: error: argument 4 of type 'u8[16]' {aka 'unsigned 
>>>> char[16]'} with mismatched bound [-Werror=array-parameter=]
>>>>    865 |     u8 ct[16])
> 
> I think this is an erroneous compiler warning.
> 
> It has been idiomatic in some codebases for a long time to write
>     const unsigned char[]
> as a formal parameter for an array (of whatever size).
> 
>>>> .../xen/include/xen/string.h:101:27: error: '__builtin_memcmp' specified 
>>>> bound 4 exceeds source size 0 [-Werror=stringop-overread]
>>>>    101 | #define memcmp(s1, s2, n) __builtin_memcmp(s1, s2, n)
>>>>        |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> mpparse.c:722:13: note: in expansion of macro 'memcmp'
>>>>    722 |         if (memcmp(mpf->mpf_signature, "_MP_", 4) == 0 &&
>>>>        |             ^~~~~~
>>>>
>>>> Clearly neither the 1st nor the 2nd argument have a "source size" of 0.
>>>
>>> It looks like there is a report on the redhat bug tracker for it [1]. Do 
>>> you know if there is a bug report on the GCC tracker as well?
>>
>> I have no idea, to be honest.
> 
> This erroneous message makes me think that there is simply a bug in
> this version of GCC, where formal parameters declared as
>     const unsigned char[]
> are treated as
>     const unsigned char[0]
> rather than as
>     const unsigned char*

I don't think so, no. In addition to what Julien has said, I think
the intention here is that the compiler can check that both consumer
and producers of arguments obey to the strictest available bounds of
such an array, no matter that at the syntactic level char[N] and
char[] both convert to char* when used in prototypes.

Jan