--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Kees Cook <keescook@chromium.org> writes:

> + * struct flex_array_struct_example {
> + *	...			 // arbitrary members
> + *	bounded_flex_array(
> + *		u16, part_count, // count of elements stored in "parts" below.
> + *		u32, parts	 // flexible array with elements of type u32.
> + *	);
> + * );

> + * struct flex_array_struct_example {
> + *	...		// position-sensitive members
> + *	// count of elements stored in "parts" below.
> + *	DECLARE_FAS_COUNT(u16, part_count);
> + *	..		// position-sensitive members
> + *	// flexible array with elements of type u32.
> + *	DECLARE_FAS_ARRAY(u32, parts);
> + * };

I'm sure there's a good reason, but these two macros appear to be doing
similar things and yet have very different naming conventions. Maybe:

        FAS_DECLARE_COUNT(type, name)
        FAS_DECLARE_ARRAY(type, name)
        FAS_DECLARE(size_type, size_name, array_type, array_name)

> +/* For use with flexible array structure helpers, in <linux/flex_array.h=
> */
> +#define __DECLARE_FAS_COUNT(TYPE, NAME)					\
> +	union {								\
> +		TYPE __flex_array_elements_count;			\
> +		TYPE NAME;						\
> +	}

How often could that second "public" member be 'const'? That would catch
places which accidentally assign to this field.

For code which does want to write to this field, is it mostly trimming
data from the end, or does it actually smash in arbitrary values? For
the former case, would it be helpful to have a test to make sure the
assigned size isn't larger than the real size (yeah, that would probably
take an extra field holding the real size), or larger than the current size?

=2D-=20
=2Dkeith

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAmNW2tcACgkQ2yIaaQAA
ABGa6A//WlcPIt1OZ72U5DGohaUla3vfRSTFFWeGl9RRAdiWSeidLKpuq8iGBpWU
+/2UygeNpW3KV9kJe4WCX/+PLAd2aGmRD1Me7OP+FdHj3FTa5iBEClfjg782geI1
5yQoGtsM3rujUSRAdlFTBF0S/n7YLE4JqtR51nCSu/jSsJ1GLbi9Yk5Wice/PsKL
0B7UU1Jl1QPQI6+q/LkCarAizF3/yKnAqVHgKCWAz2neKmd/8JgXdsaX9Kj5GVjV
q6CoXbrblbybvqaoV6LOARGs92rS55nFAIELZ6nmBdq3jfdpMlaSjGDh1NeIOM+o
f4Ls+kewrBIKYQljausRJ3YAcWXZNcprnmPr4dQx2iygqcIpe2B5nH/wGwqbiKCK
dXx8k33WjYJt0AbI9KZmJod52r1qsXk9sSiM/fOeIJ25J2GzCC4i/QjHEuopWdkp
qMLDnSKQQrPyCTR52csOgHqSvL1cbmkBWyIrzZcMdMGvbTBPNiKBIhOQU/ijSh7g
vM1sGPaRosgsgHgVMaLXDnUrrS6Lo0TwEM/43tt1KBSADkRx7K9pvhhh+yae3cK3
KGqj7Rk+acwhC8LMU82VTC557ZNSfnzeQaT0AFZ3wQBVJXt61y2eAqkIRIS4PIKM
iXFH76M95WGwitiO4kvqsEgcJkypic0/pYpAWAlMljyT6BJ2c9M=
=g28z
-----END PGP SIGNATURE-----
--=-=-=--