linux-kernel - Re: [PATCH] docs: use flexible array members, not zero-length

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 28 Sep 2019 01:16:39 -0600
From:   Jonathan Corbet <corbet@....net>
To:     Stephen Kitt <steve@....org>
Cc:     linux-doc@...r.kernel.org, bpf@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-remoteproc@...r.kernel.org,
        linux-can@...r.kernel.org, linux-afs@...ts.infradead.org,
        kvm@...r.kernel.org,
        "Gustavo A . R . Silva" <gustavo@...eddedor.com>
Subject: Re: [PATCH] docs: use flexible array members, not zero-length

On Fri, 27 Sep 2019 16:29:27 +0200
Stephen Kitt <steve@....org> wrote:

> Update the docs throughout to remove zero-length arrays, replacing
> them with C99 flexible array members. GCC will then ensure that the
> arrays are always the last element in the struct.

I appreciate the thought but...

> diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst
> index 4d565d202ce3..24ce50fc1fc1 100644
> --- a/Documentation/bpf/btf.rst
> +++ b/Documentation/bpf/btf.rst
> @@ -670,7 +670,7 @@ func_info for each specific ELF section.::
>          __u32   sec_name_off; /* offset to section name */
>          __u32   num_info;
>          /* Followed by num_info * record_size number of bytes */
> -        __u8    data[0];
> +        __u8    data[];
>       };

I only checked this one, but found what I had expected: the actual
definition of this structure (found in tools/lib/bpf/libbpf_internal.h)
says "data[0]".  We can't really make the documentation read the way we
*wish* the source would be, we need to document reality.

I'm pretty sure that most of the other examples will be the same.

If you really want to fix these, the right solution is to fix the offending
structures — one patch per structure — in the source, then update the
documentation to match the new reality.

Thanks,

jon