From nobody Fri Sep 19 01:44:28 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 4cSb0P2vVPz68N94; Fri, 19 Sep 2025 01:44:37 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cSb0P29S5z3HMJ; Fri, 19 Sep 2025 01:44:37 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758246277; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X06QG60uTikDYql0hYo72Hf/U5Z0xB3GzKT6X433e0I=; b=P2CKMqu5UtkWOUSiKzo2TH2PrQEIyqQ2hM51NgeJsyvASOMq8HAXP5Eaqa172Eq6hHQEaI ZHx25B3JA9BsGw8DRNlQ6Nom6OBhRhpQL7zrzJXQihnnU+lAq7s1y+JvbSenq/WRGLfo2y 5uDlqM4eb+J9TkrtXOP1ebJ/JbX8kJ76CBtSC1CwAf/yiw2TjOPQh5xc83o19w4yy4Ce1h zSPojygJMlIUQA/ZYB7BYCS+XgI+xP+6XHMSl8Nvb94YwATNAUiXdCbKPoyr5a+goDYIHc j8Rp8eVyiveugaVldNrWRds9U8Sh/ea+FJAAcnkyrg6uSvz1sFLeOhl/GooSsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758246277; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X06QG60uTikDYql0hYo72Hf/U5Z0xB3GzKT6X433e0I=; b=Xt/0TObugQavk88W2y/eTKlKM7pO+Ts6vyWSjdHcr/vckb2KnVaoC5rzzsFt71FjlM4byT bLpokjnMJAG4wxB5aM2KTMnqeiDBrLVsSfSRIrdzOOmO4tIvkKd6xPk0HVCIrZCMh17HGu ExDnltWpawtwOdhvpIdSuMBfm40Q4brV5DFHFYhhpmLNYAlcDTaI30a366+GaRm6dQmStX oLIGqlmB2Idhqt1x1pp+ph9moZGUrZnA3gSbJgP5p89Nzsu3FoHCrcZELaeyQm6teuGNZf MfoqZL9i2hp+W/i4C4wgBJMagm3bnW/fe99qcZuqB/k+ZUex2hA23k/sxKskPQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758246277; a=rsa-sha256; cv=none; b=oCdg6RNLgsWVrmuQOH6pRJhUl87jCCMNhahr3/Xq6CbvaCRM5/gP3ddKOl1tOzyYp+0JZm W/XSzJDIMYz1kGt5wDjY3hDc8zIcyUp2lC2VTMOttyw40+aTVHy79LEiIIlll1IQ7LpsQM 8Pmv1R/G63my4J/GYjzbxgBXpvBaCZ+mtCFFg+FL94NpHzu7VV/s5wau8RwfeiSkL6NX8E AkJps1IngCfvVQ0ZVxws8oKyycVs6UofuqsyxGPCtoINCzdOvrThGfyoPHuXugU7T2P7sq uqdDkvAHA4G20aTeF1orX4EHeM4Tnj1MJUdFmoMFv3XUav2ZDn8ZZioUdIoJMA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cSb0M3kfWz10nF; Fri, 19 Sep 2025 01:44:35 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: Build failure with Clang/LLVM 22 due to alloc-size diagnostic From: Zhenlei Huang In-Reply-To: <4985340.OV4Wx5bFTl@localhost> Date: Fri, 19 Sep 2025 09:44:28 +0800 Cc: Nakayama Kenjiro , freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B7C5718-5F5E-46FB-BB97-0F75FB5CD117@FreeBSD.org> <4985340.OV4Wx5bFTl@localhost> To: Paul Vixie X-Mailer: Apple Mail (2.3696.120.41.1.10) > On Sep 19, 2025, at 3:42 AM, Paul Vixie wrote: >=20 > On Donderdag 18 September 2025 14:29:36 UTC Zhenlei Huang wrote: > > > On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro = > > > ... > > > 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 ! >=20 > 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. >=20 > -- > Paul Vixie Best regards, Zhenlei