linux-kernel - Re: [PATCH] firewire: firewire-cdev.h: Avoid the use of one-element array

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <d7d33292-99a3-cddf-629b-a71acd1a7bee@embeddedor.com>
Date:   Thu, 30 Jul 2020 07:52:03 -0500
From:   "Gustavo A. R. Silva" <gustavo@...eddedor.com>
To:     Qianli Zhao <zhaoqianligood@...il.com>, stefanr@...6.in-berlin.de,
        linux1394-devel@...ts.sourceforge.net
Cc:     linux-kernel@...r.kernel.org, zhaoqianli@...omi.com
Subject: Re: [PATCH] firewire: firewire-cdev.h: Avoid the use of one-element
 array


NACK!

Please, stop doing this. You clearly don't know what you're doing.
You're just blindly copying/pasting all this. The subject line
has nothing to do with what the patch does and we don't want
any of these transformations in UAPI for now.

As I already said here:
https://lore.kernel.org/lkml/90b2c9f3-cc2b-b2e6-51ef-998d2f79123a@embeddedor.com/

start with drivers/staging/ and get hang of the kernel development
process, first. This is a great source, I encourage you to read it
thoroughly:
https://kernelnewbies.org/Outreachyfirstpatch

If you want to land your first kernel patch, blindly copying/pasting
stuff without actually paying attention to what you're doing, is
certainly not the best strategy and you won't start with the right
foot in terms of your reputation. Stop this and do things right from
the beginning.

--
Gustavo

On 7/29/20 22:27, Qianli Zhao wrote:
> From: Qianli Zhao <zhaoqianli@...omi.com>
> 
> There is a regular need in the kernel to provide a way to declare having a
> dynamically sized set of trailing elements in a structure. Kernel code should
> always use “flexible array members”[1] for these cases. The older style of
> one-element or zero-length arrays should no longer be used[2].
> 
> [1] https://en.wikipedia.org/wiki/Flexible_array_member
> [2] https://github.com/KSPP/linux/issues/21
> 
> Signed-off-by: Qianli Zhao <zhaoqianli@...omi.com>
> ---
>  include/uapi/linux/firewire-cdev.h | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/include/uapi/linux/firewire-cdev.h b/include/uapi/linux/firewire-cdev.h
> index 7e5b5c1..487de87f 100644
> --- a/include/uapi/linux/firewire-cdev.h
> +++ b/include/uapi/linux/firewire-cdev.h
> @@ -118,7 +118,7 @@ struct fw_cdev_event_response {
>  	__u32 type;
>  	__u32 rcode;
>  	__u32 length;
> -	__u32 data[0];
> +	__u32 data[];
>  };
>  
>  /**
> @@ -142,7 +142,7 @@ struct fw_cdev_event_request {
>  	__u64 offset;
>  	__u32 handle;
>  	__u32 length;
> -	__u32 data[0];
> +	__u32 data[];
>  };
>  
>  /**
> @@ -205,7 +205,7 @@ struct fw_cdev_event_request2 {
>  	__u32 generation;
>  	__u32 handle;
>  	__u32 length;
> -	__u32 data[0];
> +	__u32 data[];
>  };
>  
>  /**
> @@ -344,7 +344,7 @@ struct fw_cdev_event_iso_resource {
>   * @data:	Incoming data
>   *
>   * If @type is %FW_CDEV_EVENT_PHY_PACKET_SENT, @length is 0 and @data empty,
> - * except in case of a ping packet:  Then, @length is 4, and @data[0] is the
> + * except in case of a ping packet:  Then, @length is 4, and @data[] is the
>   * ping time in 49.152MHz clocks if @rcode is %RCODE_COMPLETE.
>   *
>   * If @type is %FW_CDEV_EVENT_PHY_PACKET_RECEIVED, @length is 8 and @data
> @@ -355,7 +355,7 @@ struct fw_cdev_event_phy_packet {
>  	__u32 type;
>  	__u32 rcode;
>  	__u32 length;
> -	__u32 data[0];
> +	__u32 data[];
>  };
>  
>  /**
>