Re: [PATCH] s390/vfio-ap: Replace one-element array with flexible array member

[Halil Pasic <pasic@linux.ibm.com>]

On Thu, 16 Jan 2025 14:18:59 +0100
Thorsten Blum <thorsten.blum@linux.dev> wrote:

> Replace the deprecated one-element array with a modern flexible array
> member in the struct ap_matrix_dev.
> 

I'm not sure I understand the value of this. What we have here is not
a flexible array but a one element array. Something that in the generic
case could be many but particularly for vfio-ap is always one.

Imagine if we had exactly 2 supported mdev types. I guess you would not
come to the idea that the array of two needs to be changed to a modern
flexible array. Or am I wrong about that?

So I suppose the problem  here is that arrays of one are under general
suspicion of not actually being arrays of one but a pre C99 way of
doing flexible arrays. I kind of do understand that an array wih
one element is funny. But I think the current declaration of
struct ap_matrix_dev is more expressive the proposed one.

Now I understand that it is easy to grep for [1], but it is much
harder to tell.

I've checked in Documentation/process/coding-style.rst did not see this
documented. But then I checked in checkpatch.pl and it indeed seems to
warn about it and refer to
https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays

But as far as I can tell it is also talking about the case where one
needs a trailing array of an at compile time unknown size, and not
about the case where all we need is just one element and it happens
to be convenient to have it in an array.

If there is community consensus that one sized arrays are bad regardless
of what they are used for, then the one sized array has to go.

But please tell me what speaks against replacing it with a single
pointer and then taking passing in that pointers address into
mdev_register_parent()?


> Use struct_size() to calculate the number of bytes to allocate for
> matrix_dev with a single mdev_type.
> 
> Link: https://github.com/KSPP/linux/issues/79
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>