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

[Junio C Hamano <gitster@pobox.com>]

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

>> > +			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.