From nobody Thu Sep 18 14:29:36 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 4cSJ1t5ztzz67THB; Thu, 18 Sep 2025 14:29:54 +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 4cSJ1t5Gzbz3q3L; Thu, 18 Sep 2025 14:29:54 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758205794; 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: in-reply-to:in-reply-to:references:references; bh=sIhkdUe8XYKoeHTyF7l0ag9J+3XOBP6fBaY/msUHF5k=; b=Fvp+mw4r8RfFtySXxFqfUGltJRD50gRyTupGDLGLWinoSQGBw09n9BUUnGi0Kh29lheR+j Ar2R+qy5pYwSYtY28BFBYC1nD+HR9mTTeaKPWH/XTBxqgS0phDygs36dQ8y1ktvmKXuT99 FLYMvPpXA88OJZUfg1KuXJ2GuprXvlmNR3vtHy5Bk4KRmafWuUXildd62C3+cCz1yO06Ba umA4/OMhQa9GYMxz+kAwoXJ+iDv5ktZ0EOM+qH/4lj43IgGl5K2xP9BgAjmiGPN8r36eLS AGDQd6HLQ4vHAuv4jTj9shqOXITgfFA0ZW7Poql5QiggeOOwaPiUlXZwXp/OaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758205794; 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: in-reply-to:in-reply-to:references:references; bh=sIhkdUe8XYKoeHTyF7l0ag9J+3XOBP6fBaY/msUHF5k=; b=D2sBBnkFOttTnQJ/NXSrCMnVUX5BSYwm2bp8ZdGGlngaNjQ0LgAyFxg13HJ4pw2vRD9sy5 Mq4OfhGRb1A7pXHttPJSmNEkL2f43935H4A8dg1xxNcqGv2bzuOimlfqQLZS5kW7bCgI9U oLn1+aVmpFUNk5amDS0y5EOPsb6ReSAYVhxFrTAaWdGP2DCkI2V49PJZ0aLLkEIzP0+20f /3tX19AVa0LMJujDWHr2k9bq764VFNrb5hxY1oEixvA1+xNR0rfUC//KC1EEdMy5Uj01ow 2W6fhn0OPzud+Jt/Itg2UOI4tfqJ/L/mEozqQt4E7Zfm9IqC0T1oJb/0eyg1/Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758205794; a=rsa-sha256; cv=none; b=jO26hy03tAEvR0Iw/TcdXlCoLVvlKHSL5sZ5qDmf9Z97Z+cBjMV/lmwyFHIZBW0/VayT06 AjVTNFF8aE0DyyoY/1yHuRJA5fTS95NRBDBwUpnVl+Uwi+nQt+xWE+J53gosO30joCy26D 0Hea/P3FiVWGMwtRNAAp4p5RwnoM0xMtV+To3Dpz1QqMyNusFgMcrJCcIbPQg4J3PiPBDg gWmMh5EKedlAxOF96fhQkfsUVeJJe12cxSymm7TxDn223VCC1IeVgNnlG8YScJ/bk3pRQt BmknbOzaUjshgHiCLzCYjSpXvAUKTcZXCAKalmXDH1fxOUfAUly7BvN8OwfEDA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2001:19f0:6001:9db:98f0:9fe0:3545:10]) (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 4cSJ1q1jPjzl6W; Thu, 18 Sep 2025 14:29:50 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <9B7C5718-5F5E-46FB-BB97-0F75FB5CD117@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_EB7F8416-2F5E-4DD6-A63A-B90158FE5A54" 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 Date: Thu, 18 Sep 2025 22:29:36 +0800 In-Reply-To: Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org To: Nakayama Kenjiro References: X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_EB7F8416-2F5E-4DD6-A63A-B90158FE5A54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro = wrote: >=20 > Hi, >=20 > There is a new diagnostic, alloc-size, in clang of LLVM22 that warns = if the size given to a malloc is smaller than the size of the struct = pointed to by its destination - = https://github.com/llvm/llvm-project/pull/150028 = > When we enable this option, in_mcast.c triggers this diagnostic, = causing the build to fail. >=20 > ``` > freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of = insufficient size '40' for type 'struct ip_msource' with size '48' = [-Werror,-Walloc-size] > 749 | nims =3D malloc(sizeof(struct in_msource), = M_INMFILTER, > | ^ > ``` >=20 > = https://github.com/freebsd/freebsd-src/blob/stable/15/sys/netinet/in_mcast= .c#L749 = > ``` > static int > imf_get_source(struct in_mfilter *imf, const struct sockaddr_in *psin, > struct in_msource **plims) > { > ... > struct ip_msource *ims, *nims; > ... > nims =3D malloc(sizeof(struct in_msource), M_INMFILTER, > M_NOWAIT | M_ZERO); 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 > As the error message explained, the mismatch between struct ip_msource = * and malloc(sizeof(struct in_msource)) triggers the error. >=20 > However, when reading the source code carefully, it seems that *nims = is intentionally of type ip_msource instead of in_msource. > I would like to build with LLVM's alloc-size option enabled, but does = anyone have any good ideas on how to address this problem? Or would it = be better to report it as a false positive to LLVM? Though, I am aware = that there is a workaround to partially disable this option... Best regards, Zhenlei --Apple-Mail=_EB7F8416-2F5E-4DD6-A63A-B90158FE5A54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro <nakayamakenjiro@gmail.com> wrote:

Hi,

There is a new diagnostic, alloc-size, = in clang of LLVM22 that warns if the size given to a malloc is smaller = than the size of the struct pointed to by its destination - https://github.com/llvm/llvm-project/pull/150028
When we enable this option, in_mcast.c triggers this = diagnostic, causing the build to fail.

```freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of = insufficient size '40' for type 'struct ip_msource' with size '48' = [-Werror,-Walloc-size]
  749 |       =           nims =3D malloc(sizeof(struct = in_msource), M_INMFILTER,
      |   =                     =  ^
```

https://github.com/freebsd/freebsd-src/blob/stable/15/sys/netin= et/in_mcast.c#L749
```
static int
imf_get_source(struct in_mfilter *imf, const struct = sockaddr_in *psin,
    struct in_msource = **plims)
{
        =   ...
struct ip_msource *ims, *nims;
  ...
nims =3D = malloc(sizeof(struct in_msource), M_INMFILTER,
=    M_NOWAIT | M_ZERO);

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 !

```

As the error message = explained, the mismatch between struct ip_msource * and = malloc(sizeof(struct in_msource)) triggers the error.

However, when reading the source code carefully, it seems = that *nims is intentionally of type ip_msource instead of in_msource.
I would like to build with LLVM's alloc-size option enabled, = but does anyone have any good ideas on how to address this problem? Or = would it be better to report it as a false positive to LLVM? Though, I = am aware that there is a workaround to partially disable this = option...

Best regards,
Zhenlei

= --Apple-Mail=_EB7F8416-2F5E-4DD6-A63A-B90158FE5A54--