Re: [PATCH] Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[Luiz Augusto von Dentz]

Hi Zijun,

On Mon, Nov 9, 2026 at 10:35 AM Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
>
> Hi Zijun,
>
> On Mon, Nov 9, 2026 at 8:21 AM Zijun Hu <zijun.hu@xxxxxxxxxxxxxxxx> wrote:
> >
> > On 11/8/2026 12:20 PM, Hex Lindqvist wrote:
> > > struct qhci_vse_memdump declares segdata as a zero-length array in a
> > > union. Zero-length arrays are deprecated [1], so use DECLARE_FLEX_ARRAY()
> > > instead.
> > >
> > > No functional change: segdata is only used with offsetof(). With debug
> > > info stripped, btusb.o is byte-for-byte identical before and after,
> > > built with GCC 16 and Clang 21 on x86_64 and GCC 16 on arm64, with
> > > UBSAN_BOUNDS and FORTIFY_SOURCE enabled.
> > >
> > > An AI assistant helped find and check this change and drafted this
> > > message.
> > >
> > > Link: https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [1]
> > > Signed-off-by: Hex Lindqvist <hex@xxxxxxxxxxxxx>
> > > ---
> > >  drivers/bluetooth/btusb_qcom.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/bluetooth/btusb_qcom.c b/drivers/bluetooth/btusb_qcom.c
> > > index cc4cfcde2afa..97be9078e045 100644
> > > --- a/drivers/bluetooth/btusb_qcom.c
> > > +++ b/drivers/bluetooth/btusb_qcom.c
> > > @@ -533,7 +533,7 @@ struct qhci_vse_memdump {
> > >       __le16 seqno;
> > >       u8     subsys;
> > >       union {
> > > -             u8 segdata[0];
> > > +             DECLARE_FLEX_ARRAY(u8, segdata);
> > >               struct {
> > >                       __le32 dump_size;
> > >                       u8 first_segdata[];
> >
> > NAK. Please keep this as-is. since:
> >
> > 1) segdata[0] is a familiar GNU C idiom and, since it is only used as an offsetof() anchor, is more straightforward than the
> >   DECLARE_FLEX_ARRAY() expansion.

Maybe not DECLARE_FLEX_ARRAY, but [0] is not recommended for vla see
the Link tag, in fact the first_segdata[] does follow it so this needs
to be fixed anyway.

> > 2) I guess this kind of isolated cleanup may not be welcome.As noted in Documentation/process/maintainer-netdev.rst, simple cleanups outside
> >    the context of other work are discouraged
>
> While this maybe true if the above code does produce new warnings then
> it needs to be fixed anyway, from the commit message it doesn't
> mention any build warning but that perhaps is because it is enclosed
> into a union which mask it or something, anyway trainling variable
> length should be accompany with __counted_by; so the compiler can do
> bounds checking.
>
> --
> Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz