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

Carlo Marcelo Arenas Belón [off-list ref] writes:

quoted

quoted

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