From: Junio C Hamano Date: Wed, 02 Jul 2025 22:59:59 GMT Subject: Re: [PATCH v3] builtin/gc: correct total_ram calculation with HAVE_BSD_SYSCTL Message-ID: In-Reply-To: Carlo Marcelo Arenas Belón 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.