Re: [PATCH v3] builtin/gc: correct total_ram calculation with HAVE_BSD_SYSCTL

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 2, 2025, 22:59 UTC
Message-ID: <xmqq1pqyci6o.fsf@gitster.g>
In-Reply-To: <ep4q5xwbys4qwpkmmo5jujzjorrb24v5na4yuwpjr5owojwk2q@omb7xpp4oov5>

Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:

Show 9 quoted lines

>> > +			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 shifting was meant to be a cooler way to get those bits cleared,
> because I thought that relying in the initialization wasn't as cool
> from the previous comments.

I more often have seen a pattern like

	physical_memory &= ((1U << bits) - 1);

for clearing the upper bits, but that's fine.

> a fixed version of this, would allow at least a better return, and
> because most of the extra work is only needed in Big Endian (which
> could only affect Power) then it is almost a free upgrade.

OK. As this is not a performance-critical operation anyway, I am perfectly OK with the dumb "we ask for 8 and be happy if the answer is 8 bytes long. Otherwise if the answer is 4, we prepare a u32 and ask again with 4; other "possible" answer width like 2 or 6 are probably not worth worrying about" ;-).

Thanks.