g1SE23mRxh2E0XzIy+rLiNo3Wkdy3B702wUcOz2cfzAfkiSsp/mLONrNIf11rEByZ1 5FeMRA2AmfxxbdSCkkQY/94zCLr1iYYMKi95Q4bVebwqIlUt1EmXwIRB9CCQCw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1760985369; a=rsa-sha256; cv=none; b=VxWab6N8V6TCYpRPy1fL7OcjAdonx84fgU6vgoBW060yADcR8ieewmDK0SL2MJQi7r+ctf 4AZx6rKfBy/eTtm/Ip7r1nZWLVqSyYVxZx6utaM8Tfclxe7JBoXcukN3OnTFQeNfWsP/bi Jgd4/t6kPZphSNWS1cXTK1PSm9AdqbLyaN5rlwwUw2zzbjcsC2L8HipkGRUgUD6RXjxHAc lm0C0H9qMwcugIEXXz9UIIFAj5UoShrfDNdDrP1PpWIQ+Or1lofC8Urx5grC5rYc0fTAl3 pZ3YeqcaSMgreL5b5cRGxQHey/FZpyKJf9cMF3awaKNZZc8KKmPebsmpTbAMHg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2601:5c0:4202:5670:ecba:d7d9:9ea9:ce3c] (unknown [IPv6:2601:5c0:4202:5670:ecba:d7d9:9ea9:ce3c]) (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 did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cr3zF46nbz1BlP; Mon, 20 Oct 2025 18:36:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <7af6661d-bcb1-440a-9497-92e2d0c214f8@FreeBSD.org> Date: Mon, 20 Oct 2025 14:36:08 -0400 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: git: 195b00ec45e5 - main - quot: Clean up Content-Language: en-US To: Ryan Libby , =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202510171155.59HBtMCp004658@gitrepo.freebsd.org> <86h5vt4ja9.fsf@ltc.des.dev> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/20/25 13:15, Ryan Libby wrote: > On Mon, Oct 20, 2025 at 9:42 AM Dag-Erling Smørgrav wrote: >> >> Ryan Libby writes: >>> Dag-Erling Smørgrav writes: >>>> In function 'usrrehash', >>>> inlined from 'user' at /workspace/src/usr.sbin/quot/quot.c:244:3: >>>> /workspace/src/usr.sbin/quot/quot.c:210:22: error: argument 1 range [18446744071562067968, 18446744073709551615] exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=] >>>> 210 | if ((users = calloc(nusers, sizeof(*users))) == NULL) >>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> In file included from /workspace/src/usr.sbin/quot/quot.c:51: >>>> /tmp/obj/workspace/src/amd64.amd64/tmp/usr/include/stdlib.h: In function 'user': >>>> /tmp/obj/workspace/src/amd64.amd64/tmp/usr/include/stdlib.h:92:10: >>>> note: in a call to allocation function 'calloc' declared here >>>> 92 | void *calloc(size_t, size_t) __malloc_like __result_use_check >>>> | ^~~~~~ >>> >>> Probably it is from >>> -WARNS?= 2 >>> >>> I think gcc is saying that it thinks nusers may be negative. >> >> It's saying nusers may be large enough that the result of multiplying it >> by sizeof(*users) exceeds an arbitrary threshold, which is technically >> true but completely unhelpful. This gcc option should not be used. >> >> DES >> -- >> Dag-Erling Smørgrav - des@FreeBSD.org > > The message is poor but the limit is not so arbitrary, it is > PTRDIFF_MAX. It's saying that (size_t)nusers may be huge, because it > infers that nusers, being signed, may be negative -- though in reality > it will not be negative. It says the range that will result in huge > values, (size_t)INT_MIN through (size_t)-1. > > Sure, you could disable the warning, kern.mk does that and one other > user make file does too. Or you could convince gcc with a type > constraint, or somehow else. In any case, we should fix the gcc build. Also, the GCC option is not intentionally used, it is just enabled by -Wall. I think disabling it the way we do for krb5 is ok. The only debate I guess is if we should just disable it in userland globally instead of only for quot(8). -- John Baldwin