Re: git: 195b00ec45e5 - main - quot: Clean up

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Mon, 20 Oct 2025 18:36:08 UTC
On 10/20/25 13:15, Ryan Libby wrote:
> On Mon, Oct 20, 2025 at 9:42 AM Dag-Erling Smørgrav <des@freebsd.org> wrote:
>>
>> Ryan Libby <rlibby@gmail.com> writes:
>>> Dag-Erling Smørgrav <des@freebsd.org> 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