Re: Build failure with Clang/LLVM 22 due to alloc-size diagnostic

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 AM Zhenlei Huang <zlei@freebsd.org> wrote:

>
>
> > 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 = (struct in_msource *)nims;
> > > ```
> > >
> > > So probably assign the alloced memory directly to lims would make Clang
> > > happy, say ```
> > > lims = malloc(sizeof( .... ;
> > > nims = (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 type
> 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 out
> 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
>
>

-- 
Kenjiro NAKAYAMA <nakayamakenjiro@gmail.com>
GPG Key fingerprint = ED8F 049D E67A 727D 9A44  8E25 F44B E208 C946 5EB9