Date: Tue, 23 Sep 2025 08:37:09 +0900 From: Nakayama Kenjiro <nakayamakenjiro@gmail.com> To: Zhenlei Huang <zlei@freebsd.org> Cc: Paul Vixie <paul@redbarn.org>, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Build failure with Clang/LLVM 22 due to alloc-size diagnostic Message-ID: <CAA_ZtA82KGOu5y1UxrxUHiEA%2BGqz5pz%2BU1ZaZP73xZKFSzVhrA@mail.gmail.com> In-Reply-To: <C796D9EE-0D88-48E3-8F60-7F783BDB581B@FreeBSD.org> References: <CAA_ZtA_184k892=5v0OtZsjweWSgSCX%2BWWR6se_aVCJCAh-apQ@mail.gmail.com> <9B7C5718-5F5E-46FB-BB97-0F75FB5CD117@FreeBSD.org> <4985340.OV4Wx5bFTl@localhost> <C796D9EE-0D88-48E3-8F60-7F783BDB581B@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000fc740a063f6c4cce
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thank you, Zhenlei and Paul
> I'm not sure how many type casts like this will make Clang unhappy, but I
think the first step would be turning the warning on but not fail the
build, so that it is easy to do statistic and then plan what to do next.
It might depend on the build options, but as far as I can tell, the only
code that actually triggers the alloc-size diagnostic is the mcast code I
reported.
So it would be great if that code could be fixed. We could verify that
Zhenlei's suggestion can avoid the diagnostic, although using a union{}
might be the ideal solution.
Would it make sense to open a Bugzilla ticket for this?
On Fri, Sep 19, 2025 at 10:44=E2=80=AFAM Zhenlei Huang <zlei@freebsd.org> w=
rote:
>
>
> > On Sep 19, 2025, at 3:42 AM, Paul Vixie <paul@redbarn.org> wrote:
> >
> > On Donderdag 18 September 2025 14:29:36 UTC Zhenlei Huang wrote:
> > > > On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro <
> nakayamakenjiro@gmail.com>
> > > > ...
> > > > freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of
> insufficient
> > > > size '40' for type 'struct ip_msource' with size '48'
> > > > ...
> > > The following lines has this
> > > ```
> > > lims =3D (struct in_msource *)nims;
> > > ```
> > >
> > > So probably assign the alloced memory directly to lims would make Cla=
ng
> > > happy, say ```
> > > lims =3D malloc(sizeof( .... ;
> > > nims =3D (struct ip_mfilter *)lims;
> > > ```
> > >
> > > You can have a try with that. Good luck with you !
> >
> > ideally, clang will eventually get around to complaining about that typ=
e
> cast on the same basis (destination points to a longer object than the
> source.) is there a reason we're not using a union{} for this data?
>
> I've no idea why not using a union, probably because it wastes a little
> memory ? In C world, basically it is the developer's duty to ensure no ou=
t
> of bounds memory access.
>
> I'm not sure how many type casts like this will make Clang unhappy, but I
> think the first step would be turning the warning on but not fail the
> build, so that it is easy to do statistic and then plan what to do next.
>
> >
> > --
> > Paul Vixie
>
> Best regards,
> Zhenlei
>
>
--=20
Kenjiro NAKAYAMA <nakayamakenjiro@gmail.com>
GPG Key fingerprint =3D ED8F 049D E67A 727D 9A44 8E25 F44B E208 C946 5EB9
--000000000000fc740a063f6c4cce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thank you, Zhenlei and Paul<br><br>> I'm not sure h=
ow many type casts like this will make Clang unhappy, but I think the first=
step would be turning the warning on but not fail the build, so that it is=
easy to do statistic and then plan what to do next.<br><br>It might depend=
on the build options, but as far as I can tell, the only code that actuall=
y triggers the alloc-size diagnostic is the mcast code I reported.<br>So it=
would be great if that code could be fixed. We could verify that Zhenlei&#=
39;s suggestion can avoid the diagnostic, although using a union{} might be=
the ideal solution.<br>Would it make sense to open a Bugzilla ticket for t=
his?<br><div><br></div></div><br><div class=3D"gmail_quote gmail_quote_cont=
ainer"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Sep 19, 2025 at 10:44=
=E2=80=AFAM Zhenlei Huang <<a href=3D"mailto:zlei@freebsd.org">zlei@free=
bsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><br>
<br>
> On Sep 19, 2025, at 3:42 AM, Paul Vixie <<a href=3D"mailto:paul@red=
barn.org" target=3D"_blank">paul@redbarn.org</a>> wrote:<br>
> <br>
> On Donderdag 18 September 2025 14:29:36 UTC Zhenlei Huang wrote:<br>
> > > On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro <<a href=3D=
"mailto:nakayamakenjiro@gmail.com" target=3D"_blank">nakayamakenjiro@gmail.=
com</a>><br>
> > > ...<br>
> > > freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of =
insufficient<br>
> > > size '40' for type 'struct ip_msource' with =
size '48'<br>
> > > ...<br>
> > The following lines has this<br>
> > ```<br>
> > lims =3D (struct in_msource *)nims;<br>
> > ```<br>
> ><br>
> > So probably assign the alloced memory directly to lims would make=
Clang<br>
> > happy, say ```<br>
> > lims =3D malloc(sizeof( .... ;<br>
> > nims =3D (struct ip_mfilter *)lims;<br>
> > ```<br>
> ><br>
> > You can have a try with that. Good luck with you !<br>
> <br>
> ideally, clang will eventually get around to complaining about that ty=
pe cast on the same basis (destination points to a longer object than the s=
ource.) is there a reason we're not using a union{} for this data?<br>
<br>
I've no idea why not using a union, probably because it wastes a little=
memory ? In C world, basically it is the developer's duty to ensure no=
out of bounds memory access.<br>
<br>
I'm not sure how many type casts like this will make Clang unhappy, but=
I think the first step would be turning the warning on but not fail the bu=
ild, so that it is easy to do statistic and then plan what to do next.<br>
<br>
> <br>
> --<br>
> Paul Vixie<br>
<br>
Best regards,<br>
Zhenlei<br>
<br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">Kenjiro NAKAYAMA <<a href=3D"mailto:nakayamak=
enjiro@gmail.com" target=3D"_blank">nakayamakenjiro@gmail.com</a>><br>GP=
G Key fingerprint =3D ED8F 049D E67A 727D 9A44=C2=A0 8E25 F44B E208 C946 5E=
B9<br></div></div>
--000000000000fc740a063f6c4cce--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAA_ZtA82KGOu5y1UxrxUHiEA%2BGqz5pz%2BU1ZaZP73xZKFSzVhrA>