From: Junio C Hamano <gitster@pobox•com>
To: "Carlo Marcelo Arenas Belón" <carenas@gmail•com>
Cc: git@vger•kernel.org, brad@comstyle•com, collin.funk1@gmail•com,
pclouds@gmail•com, ps@pks•im
Subject: Re: [PATCH v3] builtin/gc: correct total_ram calculation with HAVE_BSD_SYSCTL
Date: Wed, 02 Jul 2025 14:14:15 -0700 [thread overview]
Message-ID: <xmqq5xgacn2w.fsf@gitster.g> (raw)
In-Reply-To: <20250702202118.48742-1-carenas@gmail.com> ("Carlo Marcelo Arenas Belón"'s message of "Wed, 2 Jul 2025 13:21:18 -0700")
Carlo Marcelo Arenas Belón <carenas@gmail•com> writes:
> - length = sizeof(int64_t);
> - if (!sysctl(mib, 2, &physical_memory, &length, NULL, 0))
> + length = sizeof(physical_memory);
> + if (!sysctl(mib, 2, &physical_memory, &length, NULL, 0)) {
> + if (length < sizeof(physical_memory)) {
> + unsigned bits = (sizeof(physical_memory) - length) * 8;
> +
> + physical_memory <<= bits;
> + physical_memory >>= bits;
I do not quite understand this version. Does the correctness of
this depend on the machine having a certain byte-order?
The system call treats &physical_memory as a mere blob of bytes, and
may tell us that it filled only 4 bytes out of 8, but depending on
the endianness, left shifting 4*8 bits first may discard the real
information (i.e., big endian).
On a little endian 32-bit box, it might give us length == 4, filling
the lower half of the i64, and shifting by 32-bits to the left and
then shifting it down by 32-bits to the right may fill the upper half
with 1 if the result in the 4-byte long is more than 2GB because
the type of physical_memory is signed, and then we cast that value
to u64. Which does not sound correct, either.
Would it make more sense to pass &u64 and return it only when
length==8 as you did in v2 while removing the need to cast?
> + }
> return physical_memory;
> + }
> #elif defined(GIT_WINDOWS_NATIVE)
> MEMORYSTATUSEX memInfo;
next prev parent reply other threads:[~2025-07-02 21:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-02 14:42 [PATCH] builtin/gc: improve total_ram calculation for HAVE_BSD_SYSCTL Carlo Marcelo Arenas Belón
2025-07-02 15:23 ` Patrick Steinhardt
2025-07-02 17:04 ` Carlo Marcelo Arenas Belón
2025-07-02 15:46 ` [PATCH v2] builtin/gc: protect against sysctl() failure in total_ram Carlo Marcelo Arenas Belón
2025-07-02 18:42 ` Junio C Hamano
2025-07-02 20:22 ` Carlo Marcelo Arenas Belón
2025-07-02 20:59 ` Junio C Hamano
2025-07-02 20:21 ` [PATCH v3] builtin/gc: correct total_ram calculation with HAVE_BSD_SYSCTL Carlo Marcelo Arenas Belón
2025-07-02 21:14 ` Junio C Hamano [this message]
2025-07-02 22:42 ` Carlo Marcelo Arenas Belón
2025-07-02 22:59 ` Junio C Hamano
2025-07-03 8:01 ` [PATCH v4] " Carlo Marcelo Arenas Belón
2025-07-07 13:39 ` Junio C Hamano
2025-07-07 16:45 ` [PATCH v5] " Carlo Marcelo Arenas Belón
2025-07-07 17:09 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq5xgacn2w.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=brad@comstyle$(echo .)com \
--cc=carenas@gmail$(echo .)com \
--cc=collin.funk1@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=pclouds@gmail$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox