Date: Mon, 3 Sep 2007 19:45:39 +0000 (UTC) From: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-sparc64@freebsd.org Subject: Re: weird sparc64/-current issue!? (p7zip) Message-ID: <fbho93$2dnr$1@kemoauc.mips.inka.de> References: <20070901165653.GA38448@saturn.kn-bremen.de> <fbhcev$26p0$1@kemoauc.mips.inka.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Christian Weisgerber <naddy@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@mips.inka.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fbho93$2dnr$1>