From nobody Mon Sep 22 23:37:09 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cVzzr3TPKz68cLR for ; Mon, 22 Sep 2025 23:37:28 +0000 (UTC) (envelope-from nakayamakenjiro@gmail.com) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cVzzq4s2Wz3kYQ for ; Mon, 22 Sep 2025 23:37:27 +0000 (UTC) (envelope-from nakayamakenjiro@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=lAhIm17Z; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of nakayamakenjiro@gmail.com designates 2607:f8b0:4864:20::102b as permitted sender) smtp.mailfrom=nakayamakenjiro@gmail.com Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-330469eb750so5627336a91.2 for ; Mon, 22 Sep 2025 16:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758584241; x=1759189041; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r3FI7EezYu+S9qxPXPcOfMU3fV2lTR78y30jPwv9WnU=; b=lAhIm17ZzbgU3pdmEs/lZo55EnLE2jmOEK7+F6TACwcdx+tyOIzNV25XuyOd57XsHe 7bX4MdD5sFh16iZjJ0RczkIpz/gZkLCF1qwx6dHsvaFEP/oMwwCqgqBC0RkURxkh1Bpl vEgCD3fCKc3f0rKFhbq8pJuKvRRLD0TY+JstdUy5cXz5OX9tqymkYnmO3MJaCReZS9Z/ hOfK5db7fupnyym2rV4LZ6WWzVLI9S03H37TM5yX+DoNYjYdWldm4QTUyEUmdKASJwOp 42GXCx8bvAzC6SAO35iNGR/rS6fJXjsSMboQC36Pgh77omFduXLsLhRdpemaTGcnuVM1 mSkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758584241; x=1759189041; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r3FI7EezYu+S9qxPXPcOfMU3fV2lTR78y30jPwv9WnU=; b=dpMgxZTslNj79Y2rZmHm6PAdy7uxzw1eMLPtVxbFGqMTwXnlu67NB/er1JukpDuzxP PN16+7UCrzWaZqpyjabG5Uognjg6xectYjDYk3O0GLcK7qWjVpATEJ0BRlAoyqrmgFGM nVyNgiiIxK1GxSyLb8KVDbDmYO02HKzjq2FQb6uNP7sNfa310c4XSWKK/CFWPxNmWKRJ IgdHZLdIsWdViS0ccEUe4MWHfhdBtglIKrV97X5BGbE9BDFH4+c55uNRmvxnbl7f4xVN WjA+Gws6bKK1b9Q3MMflSh1HBJ+Qx0VI+vBz81i1SBLDsVcEksJ9t8pyR8RHdfxS4wMo 7dGA== X-Forwarded-Encrypted: i=1; AJvYcCUyVPZk38fQ3EUSLUG9WAN8OL97G14BTAFwhDBZImLEgOokwOwOZoPlePP2IgePf93iBuvhSIikj4ZL6g==@freebsd.org X-Gm-Message-State: AOJu0Yzgf4u+z3MoPpeZ56oodX1Kb+x/L9l5RsB3W0/6lSJ9+SYu+19a GbSHjjCEyZWicfKmZVlY4Anur9rLLWkoCbB5oTxhqrBLLFgSdFfzDvCgMdkW93wRuUTr3OFHChz Elyb/IC8mV/FPkmslSDfCzOsFeRu2Vbw= X-Gm-Gg: ASbGncsGF16D+N/Js2ajkYV7Pt39Q5hVKYzPjwzeuPVwiPFSFyh7fR1VAVIBLAJtWpi J4jC7lh8XWzIaVkA7Sv5B4C2iEV63BzvMvht8qI+Sy5xMnXkItrOev/ToM0vT27ulZ6Off42Rcj oFF1xZOO5Ay/0iLskC9qDnvBZfOBGM57oZtHGFQiIK6dsgnaFLs7jPMzr68IlzukXZlfWJYxFJW SZUZr9VV3uYV1k= X-Google-Smtp-Source: AGHT+IE/z3Kcfjdc44nIunWABO6HE9vWWV6s8pCkhLGb/lelEIUH3sjFISdtMJwrKZCzphz5sIn50tJ9+ltISGyUJQo= X-Received: by 2002:a17:90b:540d:b0:329:f535:6e48 with SMTP id 98e67ed59e1d1-332a9906d43mr714724a91.36.1758584240893; Mon, 22 Sep 2025 16:37:20 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 References: <9B7C5718-5F5E-46FB-BB97-0F75FB5CD117@FreeBSD.org> <4985340.OV4Wx5bFTl@localhost> In-Reply-To: From: Nakayama Kenjiro Date: Tue, 23 Sep 2025 08:37:09 +0900 X-Gm-Features: AS18NWC-QXGHF-bWuImc5j-BxRyvYHvlImFFfIP_1LtsV7nJC5vas5gkNFYkcxU Message-ID: Subject: Re: Build failure with Clang/LLVM 22 due to alloc-size diagnostic To: Zhenlei Huang Cc: Paul Vixie , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000fc740a063f6c4cce" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.65 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.65)[-0.654]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102b:from]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4cVzzq4s2Wz3kYQ --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 w= rote: > > > > On Sep 19, 2025, at 3:42 AM, Paul Vixie 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 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
Thank you, Zhenlei and Paul

> 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.

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.
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.
Would it make sense to open a Bugzilla ticket for t= his?


On Fri, Sep 19, 2025 at 10:44= =E2=80=AFAM Zhenlei Huang <zlei@free= bsd.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 =3D (struct in_msource *)nims;
> > ```
> >
> > So probably assign the alloced memory directly to lims would make= Clang
> > 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 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?

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 bu= ild, 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>
GP= G Key fingerprint =3D ED8F 049D E67A 727D 9A44=C2=A0 8E25 F44B E208 C946 5E= B9
--000000000000fc740a063f6c4cce--