2.6.0-test9 ioctl compile warnings in userspace
PATCH 1/1 2.6.0-test9 ioctl compile warnings in userspace
Hi,
the patch below fixes
warning: signed and unsigned type in conditional expression
when compiling userspace programs with a glibc built against 2.6 kernel headers.
This is a better version of my previous patch which aims to fix all affected architectures.
Johannes
include/asm-i386/ioctl.h +1 -1
@@ -52,9 +52,9 @@ ((nr) << _IOC_NRSHIFT) | \ ((size) << _IOC_SIZESHIFT))/* provoke compile error for invalid uses of size argument */ -extern int __invalid_size_argument_for_IOC; +extern unsigned int __invalid_size_argument_for_IOC;#define _IOC_TYPECHECK (t) \ ((sizeof(t) == sizeof(t[1]) && \ sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC)
include/asm-parisc/ioctl.h +1 -1
@@ -44,9 +44,9 @@ ((nr) << _IOC_NRSHIFT) | \ ((size) << _IOC_SIZESHIFT))/* provoke compile error for invalid uses of size argument */ -extern int __invalid_size_argument_for_IOC; +extern unsigned int __invalid_size_argument_for_IOC;#define _IOC_TYPECHECK (t) \ ((sizeof(t) == sizeof(t[1]) && \ sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC)
include/asm-ppc/ioctl.h +1 -1
@@ -37,9 +37,9 @@ ((nr) << _IOC_NRSHIFT) | \ ((size) << _IOC_SIZESHIFT))/* provoke compile error for invalid uses of size argument */ -extern int __invalid_size_argument_for_IOC; +extern unsigned int __invalid_size_argument_for_IOC;#define _IOC_TYPECHECK (t) \ ((sizeof(t) == sizeof(t[1]) && \ sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC)
include/asm-ppc64/ioctl.h +1 -1
@@ -42,9 +42,9 @@ ((nr) << _IOC_NRSHIFT) | \ ((size) << _IOC_SIZESHIFT))/* provoke compile error for invalid uses of size argument */ -extern int __invalid_size_argument_for_IOC; +extern unsigned int __invalid_size_argument_for_IOC;#define _IOC_TYPECHECK (t) \ ((sizeof(t) == sizeof(t[1]) && \ sizeof(t) < (1 << _IOC_SIZEBITS)) ? \ sizeof(t) : __invalid_size_argument_for_IOC)
Quoted 11 lines · Johannes Stezenbach
Hi,
the patch below fixes
warning: signed and unsigned type in conditional expression
when compiling userspace programs with a glibc built against 2.6 kernel headers.
This is a better version of my previous patch which aims to fix all affected architectures.
I am curious about this.
This patch has been proposed since almost a month or more now, and clearly nobody seems to care about this, since it didn't make it in the 2.6.0-test11 tarball (don't know about more recent bk trees though) nor do the debian glibc maintainer judge the issue important enough to act on it (despite it breaking buildage of other packages).
So, is there a reason why not to solve this problem this way, or a particular reason why __invalid_size_argument_for_IOC is still int and not unsigned int ?
Friendly,
Sven Luther
Quoted 21 lines · Sven Luther
Quoted 11 lines · Johannes Stezenbach
Hi,
the patch below fixes
warning: signed and unsigned type in conditional expression
when compiling userspace programs with a glibc built against 2.6 kernel headers.
This is a better version of my previous patch which aims to fix all affected architectures.
I am curious about this.
This patch has been proposed since almost a month or more now, and clearly nobody seems to care about this, since it didn't make it in the 2.6.0-test11 tarball (don't know about more recent bk trees though) nor do the debian glibc maintainer judge the issue important enough to act on it (despite it breaking buildage of other packages).
Quoted 3 lines
So, is there a reason why not to solve this problem this way, or a particular reason why
__invalid_size_argument_for_IOCis still int and not unsigned int ?
It doesn't clearly fix a bug, afaics. Also, most kernel hackers don't care too much about the signed/unsigned warnings, as they are 99% noise.
Resend the patch after 2.6.0 has been released, I don't see any change for it to go in before.
Jörn
Signature · 3 lines
People will accept your ideas much more readily if you tell them that Benjamin Franklin said it first. -- unknown
Quoted 22 lines · Jörn Engel
Quoted 21 lines · Sven Luther
Quoted 11 lines · Johannes Stezenbach
Hi,
the patch below fixes
warning: signed and unsigned type in conditional expression
when compiling userspace programs with a glibc built against 2.6 kernel headers.
This is a better version of my previous patch which aims to fix all affected architectures.
I am curious about this.
This patch has been proposed since almost a month or more now, and clearly nobody seems to care about this, since it didn't make it in the 2.6.0-test11 tarball (don't know about more recent bk trees though) nor do the debian glibc maintainer judge the issue important enough to act on it (despite it breaking buildage of other packages).
Quoted 7 lines
Quoted 3 lines
So, is there a reason why not to solve this problem this way, or a particular reason why
__invalid_size_argument_for_IOCis still int and not unsigned int ?It doesn't clearly fix a bug, afaics. Also, most kernel hackers don't care too much about the signed/unsigned warnings, as they are 99% noise.
Well, the main problem is that since the 2.6.0 kernel headers are used by glibc on debian (and maybe others) it makes building userland packages about this difficult. I was asking to know if there was something inherently bad about implementing this in the userland kernel headers provided by the glibc, as the glibc debian maintainers have not been responsive about this, but i know since that a fixed package will be provided once the situation resulting from the intrusion is cleared.
Quoted 2 lines
Resend the patch after 2.6.0 has been released, I don't see any change for it to go in before.
But also no particular reason not to use it, right ?
Thanks for your reply.
Friendly,
Sven Luther
Quoted 6 lines · Sven Luther
Quoted 4 lines · Jörn Engel
It doesn't clearly fix a bug, afaics. Also, most kernel hackers don't care too much about the signed/unsigned warnings, as they are 99% noise.
Quoted 7 lines
Well, the main problem is that since the 2.6.0 kernel headers are used by glibc on debian (and maybe others) it makes building userland packages about this difficult. I was asking to know if there was something inherently bad about implementing this in the userland kernel headers provided by the glibc, as the glibc debian maintainers have not been responsive about this, but i know since that a fixed package will be provided once the situation resulting from the intrusion is cleared.
The current status for userland kernel headers is "the kernel doesn't care". Let the glibc folks and whoever else gather the information from the kernel headers and create derived, but different, userland headers.
So unless you change this paradigm, your point is void, sorry.
Quoted 4 lines
Quoted 2 lines
Resend the patch after 2.6.0 has been released, I don't see any change for it to go in before.
But also no particular reason not to use it, right ?
Stability, stability, stability - are three reasons enough? ;)
Linus wants to have very few patches these days and all of them have to fix a real bug. Please don't question him doing so, just remember the 2.4 days with slashdot stories like "kernel of pain".
Jörn
Signature · 3 lines
Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
Quoted 15 lines · Jörn Engel
Quoted 6 lines · Sven Luther
Quoted 4 lines · Jörn Engel
It doesn't clearly fix a bug, afaics. Also, most kernel hackers don't care too much about the signed/unsigned warnings, as they are 99% noise.
Quoted 7 lines
Well, the main problem is that since the 2.6.0 kernel headers are used by glibc on debian (and maybe others) it makes building userland packages about this difficult. I was asking to know if there was something inherently bad about implementing this in the userland kernel headers provided by the glibc, as the glibc debian maintainers have not been responsive about this, but i know since that a fixed package will be provided once the situation resulting from the intrusion is cleared.
Quoted 4 lines
The current status for userland kernel headers is "the kernel doesn't care". Let the glibc folks and whoever else gather the information from the kernel headers and create derived, but different, userland headers.
Ok, i understand.
Quoted 1 line
So unless you change this paradigm, your point is void, sorry.
Well, i just wanted to get some information about this patch. It has been posted here already in september if i am not wrong, and there were various comments, but nothing conclusive in a way or the other, so i was wondering if it was a good way to solve this or not.
Quoted 10 lines
Quoted 4 lines
Quoted 2 lines
Resend the patch after 2.6.0 has been released, I don't see any change for it to go in before.
But also no particular reason not to use it, right ?
Stability, stability, stability - are three reasons enough? ;)
Linus wants to have very few patches these days and all of them have to fix a real bug. Please don't question him doing so, just remember the 2.4 days with slashdot stories like "kernel of pain".
I never dreamed about it. I was just curious about the vailidy of the patch per se, not really its inclusion into the main trees or not.
Anyway, thanks for the information you provided, things are clearer for me now.
Friendly,
Sven Luther
Quoted 5 lines · Sven Luther
Well, i just wanted to get some information about this patch. It has been posted here already in september if i am not wrong, and there were various comments, but nothing conclusive in a way or the other, so i was wondering if it was a good way to solve this or not.
Missed the September discussion, but the patch looks good, so it should get included someday. Just not now. :)
Jörn
Signature · 2 lines
This above all: to thine own self be true. -- Shakespeare