weird sparc64/-current issue!? (p7zip)

[Juergen Lock]

On Mon, Sep 03, 2007 at 09:45:39PM +0200, Christian Weisgerber wrote:
> 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.

[Ooops, I didn't see at first you did post this to the list too!]

 Yup, hw.ncpu seems to be an int indeed, no wonder it didn't work.
So I guess I'll just patch that and wait for the next sparc64 build... :)

 Thanx again,
	Juergen