python warning
Frank Leonhardt
frank2 at fjl.co.uk
Wed Jan 8 19:19:27 UTC 2014
On 08/01/2014 18:37, Ajtim wrote:
> Hi!
>
> My system:
> FreeBSD 10.0-RC4 #0 r260130: Tue Dec 31 17:10:01 UTC 2013 root at snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
>
> I had bellow warnings in mail from version FreeBSD 10.0-ALPHA and it is still on. Do I need to make some settings or..., please?
> Thank you.
>
> +WARNING pid 1752 (python2.7): ioctl sign-extension ioctl ffffffff80087467
> +WARNING pid 1762 (python2.7): ioctl sign-extension ioctl ffffffff80087467
I hate snakes!
As to this, in case no one comes by that knows the answer, this wouldn't
worry me greatly. ioctl takes values that are unsigned long; generally
considered to be 32-bit unsigned values except when it's not. gcc
defaults to 64-bit on AMD64. I have a horrible feeling that CLANG
doesn't, and that FreeBSD 10 uses CLANG instead of gcc. I haven't been
brave enough to try it. OpenCL specifies that long will be 64-bit
regardless of platform, but that doesn't make it true.
This is obviously bleating about a 64-bit value which looks like a -ve
32-bit number (high bit set). Compilers moving a signed integer value
into a type with more bits WILL sign-extend, which means the high bit is
propagated through the "new" high-order bits. HOWEVER, when the device
driver is checking for commands it's not going to worry about the
high-order bits - if its expecting a 32-bit scalar but the architecture
gives it 64-bit instead it's not going to matter. It'll either check bit
31 (which remains unchanged) or, worst case, test for -ve (in which case
you want the sign extend). It shouldn't do this, of course, because it's
not a signed number and therefore can only be +ve. Hence the bleat.
Methinks there's probably a line in python that's calling ioctl with an
int instead of a ulong, and I bet CLANG comes in to it somewhere.
Regards, Frank.
More information about the freebsd-questions
mailing list