weird sparc64/-current issue!? (p7zip)

[Christian Weisgerber]

Christian Weisgerber <naddy at mips.inka.de> wrote:

> > 		UInt32 GetNumberOfProcessors() {
> > 		  		int nbcpu = 1;
> > 			size_t value;
> > 			size_t len = sizeof(value);
> > 			if (sysctlbyname("hw.ncpu", &value, &len, NULL, 0) == 0)
> > 				nbcpu = value;
> > 			return nbcpu;
> > 		}
> 
> Are you sure that value is of type size_t here?  I think it is an
> int.  (Remember, size_t is 64 bits on all our 64-bit platforms, int
> is 32 bits.)

I should expand on this, because it is a really tricky LP64 bug.

sysctlbyname() writes a 32-bit value to the supplied address, but
we then read a 64-bit value.  On a little-endian machine (alpha,
amd64) we get the actual value in the lower 32 bits and random
garbage in the upper 32.  Then the assignment nbcpu=value drops the
upper 32 bits.  Quite by accident, we always end up with the correct
result.

On a big-endian machine (sparc64), it's the other way around:  We
get the actual value in the upper 32 bits and random garbage in the
lower 32.  Then the assignment nbcpu=value drops the upper 32 bits.
Thus we always end up with a garbage result.

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de