diff mbox series

[next] ASoC: uapi: Replace zero-length arrays with __DECLARE_FLEX_ARRAY() helper

Message ID YzIzUjUuJKf0mkKg@work
State Accepted
Commit 97ab4c116aae4d3756a37c4d8458d49756e4cf89
Headers show
Series [next] ASoC: uapi: Replace zero-length arrays with __DECLARE_FLEX_ARRAY() helper | expand

Commit Message

Gustavo A. R. Silva Sept. 26, 2022, 11:18 p.m. UTC
Zero-length arrays are deprecated and we are moving towards adopting
C99 flexible-array members, instead. So, replace zero-length arrays
declarations in anonymous union with the new __DECLARE_FLEX_ARRAY()
helper macro.

This helper allows for flexible-array members in unions.

Link: https://github.com/KSPP/linux/issues/193
Link: https://github.com/KSPP/linux/issues/227
Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
 include/uapi/sound/asoc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Kees Cook Sept. 27, 2022, 2:33 a.m. UTC | #1
On Mon, Sep 26, 2022 at 06:18:42PM -0500, Gustavo A. R. Silva wrote:
> Zero-length arrays are deprecated and we are moving towards adopting
> C99 flexible-array members, instead. So, replace zero-length arrays
> declarations in anonymous union with the new __DECLARE_FLEX_ARRAY()
> helper macro.
> 
> This helper allows for flexible-array members in unions.
> 
> Link: https://github.com/KSPP/linux/issues/193
> Link: https://github.com/KSPP/linux/issues/227
> Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

Some day after the __element_count__ attribute exists, we might want to
consider a __type_select__ attribute to tie union members to a variable
outside the union (like the "type" member here).

Reviewed-by: Kees Cook <keescook@chromium.org>
Amadeusz Sławiński Sept. 27, 2022, 7:37 a.m. UTC | #2
On 9/27/2022 1:18 AM, Gustavo A. R. Silva wrote:
> Zero-length arrays are deprecated and we are moving towards adopting
> C99 flexible-array members, instead. So, replace zero-length arrays
> declarations in anonymous union with the new __DECLARE_FLEX_ARRAY()
> helper macro.
> 
> This helper allows for flexible-array members in unions.
> 
> Link: https://github.com/KSPP/linux/issues/193
> Link: https://github.com/KSPP/linux/issues/227
> Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>   include/uapi/sound/asoc.h | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h
> index 053949287ce8..dd8ad790fc15 100644
> --- a/include/uapi/sound/asoc.h
> +++ b/include/uapi/sound/asoc.h
> @@ -226,9 +226,9 @@ struct snd_soc_tplg_vendor_array {
>   	__le32 type;	/* SND_SOC_TPLG_TUPLE_TYPE_ */
>   	__le32 num_elems;	/* number of elements in array */
>   	union {
> -		struct snd_soc_tplg_vendor_uuid_elem uuid[0];
> -		struct snd_soc_tplg_vendor_value_elem value[0];
> -		struct snd_soc_tplg_vendor_string_elem string[0];
> +		__DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_uuid_elem, uuid);
> +		__DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_value_elem, value);
> +		__DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_string_elem, string);
>   	};
>   } __attribute__((packed));
>   

Reviewed-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Gustavo A. R. Silva Feb. 2, 2023, 8:34 p.m. UTC | #3
Hi Takashi,

I wonder if this can go through your tree.

It's already been reviewed by a couple of people. :)

Thanks
--
Gustavo

On 9/26/22 18:18, Gustavo A. R. Silva wrote:
> Zero-length arrays are deprecated and we are moving towards adopting
> C99 flexible-array members, instead. So, replace zero-length arrays
> declarations in anonymous union with the new __DECLARE_FLEX_ARRAY()
> helper macro.
> 
> This helper allows for flexible-array members in unions.
> 
> Link: https://github.com/KSPP/linux/issues/193
> Link: https://github.com/KSPP/linux/issues/227
> Link: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
>   include/uapi/sound/asoc.h | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h
> index 053949287ce8..dd8ad790fc15 100644
> --- a/include/uapi/sound/asoc.h
> +++ b/include/uapi/sound/asoc.h
> @@ -226,9 +226,9 @@ struct snd_soc_tplg_vendor_array {
>   	__le32 type;	/* SND_SOC_TPLG_TUPLE_TYPE_ */
>   	__le32 num_elems;	/* number of elements in array */
>   	union {
> -		struct snd_soc_tplg_vendor_uuid_elem uuid[0];
> -		struct snd_soc_tplg_vendor_value_elem value[0];
> -		struct snd_soc_tplg_vendor_string_elem string[0];
> +		__DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_uuid_elem, uuid);
> +		__DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_value_elem, value);
> +		__DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_string_elem, string);
>   	};
>   } __attribute__((packed));
>
Mark Brown Feb. 2, 2023, 9:09 p.m. UTC | #4
On Thu, Feb 02, 2023 at 02:34:17PM -0600, Gustavo A. R. Silva wrote:
> Hi Takashi,
> 
> I wonder if this can go through your tree.
> 
> It's already been reviewed by a couple of people. :)

As documented in submitting-patches.rst please send patches to the 
maintainers for the code you would like to change.  The normal kernel
workflow is that people apply patches from their inboxes, if they aren't
copied they are likely to not see the patch at all and it is much more
difficult to apply patches.
Gustavo A. R. Silva Feb. 2, 2023, 9:18 p.m. UTC | #5
On 2/2/23 15:09, Mark Brown wrote:
> On Thu, Feb 02, 2023 at 02:34:17PM -0600, Gustavo A. R. Silva wrote:
>> Hi Takashi,
>>
>> I wonder if this can go through your tree.
>>
>> It's already been reviewed by a couple of people. :)
> 
> As documented in submitting-patches.rst please send patches to the
> maintainers for the code you would like to change.  The normal kernel
> workflow is that people apply patches from their inboxes, if they aren't
> copied they are likely to not see the patch at all and it is much more
> difficult to apply patches.

Yep; that's exactly what I did. :)

scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback include/uapi/sound/asoc.h
Jaroslav Kysela <perex@perex.cz> (maintainer:SOUND)
Takashi Iwai <tiwai@suse.com> (maintainer:SOUND)
alsa-devel@alsa-project.org (moderated list:SOUND)
linux-kernel@vger.kernel.org (open list)

If you're one the maintainers of that file, you're clearly not listed as such.

--
Gustavo
Mark Brown Feb. 3, 2023, 12:57 p.m. UTC | #6
On Thu, Feb 02, 2023 at 03:18:47PM -0600, Gustavo A. R. Silva wrote:
> On 2/2/23 15:09, Mark Brown wrote:
> > On Thu, Feb 02, 2023 at 02:34:17PM -0600, Gustavo A. R. Silva wrote:

> > As documented in submitting-patches.rst please send patches to the
> > maintainers for the code you would like to change.  The normal kernel
> > workflow is that people apply patches from their inboxes, if they aren't
> > copied they are likely to not see the patch at all and it is much more
> > difficult to apply patches.

> Yep; that's exactly what I did. :)

> scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback include/uapi/sound/asoc.h
> Jaroslav Kysela <perex@perex.cz> (maintainer:SOUND)
> Takashi Iwai <tiwai@suse.com> (maintainer:SOUND)
> alsa-devel@alsa-project.org (moderated list:SOUND)
> linux-kernel@vger.kernel.org (open list)

> If you're one the maintainers of that file, you're clearly not listed as such.

You did manage to figure out that it's an ASoC patch given the subject
line...
Gustavo A. R. Silva Feb. 3, 2023, 1:27 p.m. UTC | #7
On 2/3/23 06:57, Mark Brown wrote:
> On Thu, Feb 02, 2023 at 03:18:47PM -0600, Gustavo A. R. Silva wrote:
>> On 2/2/23 15:09, Mark Brown wrote:
>>> On Thu, Feb 02, 2023 at 02:34:17PM -0600, Gustavo A. R. Silva wrote:
> 
>>> As documented in submitting-patches.rst please send patches to the
>>> maintainers for the code you would like to change.  The normal kernel
>>> workflow is that people apply patches from their inboxes, if they aren't
>>> copied they are likely to not see the patch at all and it is much more
>>> difficult to apply patches.
> 
>> Yep; that's exactly what I did. :)
> 
>> scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback include/uapi/sound/asoc.h
>> Jaroslav Kysela <perex@perex.cz> (maintainer:SOUND)
>> Takashi Iwai <tiwai@suse.com> (maintainer:SOUND)
>> alsa-devel@alsa-project.org (moderated list:SOUND)
>> linux-kernel@vger.kernel.org (open list)
> 
>> If you're one the maintainers of that file, you're clearly not listed as such.
> 
> You did manage to figure out that it's an ASoC patch given the subject
> line...

As with the list of maintainers, I use a tool to get that info:

git log --oneline include/uapi/sound/asoc.h

I think we have run into this same issue (you not being listed in the
MAINTAINERS file) at least once in the past, right? (thinkingface)

IMHO, the sensible solution for this is to keep the MAINTAINERS file
up-to-date. So, get_maintainer.pl can continue to be useful for people.

--
Gustavo
Mark Brown Feb. 3, 2023, 1:45 p.m. UTC | #8
On Fri, Feb 03, 2023 at 07:27:03AM -0600, Gustavo A. R. Silva wrote:

> I think we have run into this same issue (you not being listed in the
> MAINTAINERS file) at least once in the past, right? (thinkingface)

> IMHO, the sensible solution for this is to keep the MAINTAINERS file
> up-to-date. So, get_maintainer.pl can continue to be useful for people.

Sure, feel free to send an update...
Gustavo A. R. Silva Feb. 3, 2023, 1:50 p.m. UTC | #9
On 2/3/23 07:45, Mark Brown wrote:
> On Fri, Feb 03, 2023 at 07:27:03AM -0600, Gustavo A. R. Silva wrote:
> 
>> I think we have run into this same issue (you not being listed in the
>> MAINTAINERS file) at least once in the past, right? (thinkingface)
> 
>> IMHO, the sensible solution for this is to keep the MAINTAINERS file
>> up-to-date. So, get_maintainer.pl can continue to be useful for people.
> 
> Sure, feel free to send an update...

[chuckles]
Kees Cook Feb. 3, 2023, 4:29 p.m. UTC | #10
On Fri, Feb 03, 2023 at 01:45:02PM +0000, Mark Brown wrote:
> On Fri, Feb 03, 2023 at 07:27:03AM -0600, Gustavo A. R. Silva wrote:
> 
> > I think we have run into this same issue (you not being listed in the
> > MAINTAINERS file) at least once in the past, right? (thinkingface)
> 
> > IMHO, the sensible solution for this is to keep the MAINTAINERS file
> > up-to-date. So, get_maintainer.pl can continue to be useful for people.
> 
> Sure, feel free to send an update...

Is this accurate?


diff --git a/MAINTAINERS b/MAINTAINERS
index 7f86d02cb427..e21a3412a546 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19564,6 +19564,8 @@ F:	Documentation/devicetree/bindings/sound/
 F:	Documentation/sound/soc/
 F:	include/dt-bindings/sound/
 F:	include/sound/soc*
+F:	include/sound/sof/
+F:	include/uapi/sound/asoc.h
 F:	sound/soc/
 
 SOUND - SOUND OPEN FIRMWARE (SOF) DRIVERS
Mark Brown Feb. 3, 2023, 6:36 p.m. UTC | #11
On Fri, Feb 03, 2023 at 04:29:41PM +0000, Kees Cook wrote:
> On Fri, Feb 03, 2023 at 01:45:02PM +0000, Mark Brown wrote:

> > Sure, feel free to send an update...

> Is this accurate?

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7f86d02cb427..e21a3412a546 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19564,6 +19564,8 @@ F:	Documentation/devicetree/bindings/sound/
>  F:	Documentation/sound/soc/
>  F:	include/dt-bindings/sound/
>  F:	include/sound/soc*
> +F:	include/sound/sof/
> +F:	include/uapi/sound/asoc.h
>  F:	sound/soc/

Might be missing stuff but those are both good additions.  Looks like
the SOF directory also wants adding to the SOF section in MAINTAINERS.
diff mbox series

Patch

diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h
index 053949287ce8..dd8ad790fc15 100644
--- a/include/uapi/sound/asoc.h
+++ b/include/uapi/sound/asoc.h
@@ -226,9 +226,9 @@  struct snd_soc_tplg_vendor_array {
 	__le32 type;	/* SND_SOC_TPLG_TUPLE_TYPE_ */
 	__le32 num_elems;	/* number of elements in array */
 	union {
-		struct snd_soc_tplg_vendor_uuid_elem uuid[0];
-		struct snd_soc_tplg_vendor_value_elem value[0];
-		struct snd_soc_tplg_vendor_string_elem string[0];
+		__DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_uuid_elem, uuid);
+		__DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_value_elem, value);
+		__DECLARE_FLEX_ARRAY(struct snd_soc_tplg_vendor_string_elem, string);
 	};
 } __attribute__((packed));