Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-5052-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <727c93065d8d1e56e9fcd5b5bed724d63dfbe871.camel@hadess.net>
Subject: Re: [BlueZ 9/9] avdtp: Fix manipulating struct as an array
From: Bastien Nocera <hadess@hadess.net>
To: Pauli Virtanen <pav@iki.fi>, linux-bluetooth@vger.kernel.org
Date: Fri, 31 May 2024 17:50:33 +0200
In-Reply-To: <8c979897beeb8316616bb7c15f60093be177577c.camel@iki.fi>
References: <20240530150057.444585-1-hadess@hadess.net>
	 <20240530150057.444585-10-hadess@hadess.net>
	 <8c979897beeb8316616bb7c15f60093be177577c.camel@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.4 (3.50.4-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Thu, 2024-05-30 at 19:57 +0300, Pauli Virtanen wrote:
> Hi,
>=20
> to, 2024-05-30 kello 16:58 +0200, Bastien Nocera kirjoitti:
> > Don't manipulate the "req" structs as if they were flat arrays,
> > static
> > analysis and humans are both equally confused by this kind of
> > usage.
>=20
> struct start_req {
> 	union {
> 		struct seid required[1];
> 		struct seid seids[0];
> 	};
> } __attribute__ ((packed));
>=20
> and access only via req->seids?

That's a good idea, I'll give it a try.

> <snip>
> > +#define
> > REQ_GET_NTH_SEID(x)						\
> > +	static struct seid
> > *						\
> > +	x##_req_get_nth_seid(struct x##_req *req, int count, int
> > i)	\
> > +	{						=09
> > 	\
> > +		if (count =3D=3D 0 || i >=3D
> > count)				\
> > +			return
> > NULL;					\
> > +		if (i =3D=3D
> > 1)						\
> > +			return &req-
> > >first_seid;			\
> > +		return &req-
> > >other_seids[i];				\
>=20
> (i =3D=3D 0) and [i - 1]?

*facepalm*

Yes, this will need a v2, thanks for spotting that.