From: Johann D. <joh...@la...> - 2002-05-04 09:55:53
|
Brad Hards wrote: > On Sat, 4 May 2002 08:21, Johann Deneux wrote: > >>Rodrigo Damazio wrote: >> >>>Update of /cvsroot/linuxconsole/ruby/linux/include/linux >>>In directory usw-pr-cvs1:/tmp/cvs-serv2684/linux/include/linux >>> >>>Modified Files: >>> input.h >>>Log Message: >>>Fix for the types problem - uint16_t and similars are not exported >>>outside the kernel. They were replaced by __u16 and similars. fftest and >>>other utils should now compile OK. >>> >>No, uint16_t is not a kernel specific thing. __u16 is. I prefered it the >>other way. >> >>I switched from __u16 to uint16_t on the advice of Brad Hards. The point >>is that uint16_t is apparently a standard type (C99). __u16 is a >>linux-kernel specific thing (16 bit unsigned integer visible from user >>space). >>The discussion went on on linux-usb, and apparently no agreement was >>reached. >> > My reference was the Linux Device Drivers book (from O'Reilly, also available > on-line). Read the chapter on types for more info. That's actually this chapter that convinced me to change to uint16_t. > > >>The point is that input.h should include the header defining uint16_t. >> > I don't think so. The kernel routines using uint16_t should include the kernel > header <linux/types.h>, while the userspace routines should use the standard > header (<stdint.h>). > Perhaps a conditional include would do it ? I personally hate it when headers depending on other headers don't handle these dependencies by themselves, forcing the user to guess what could be the right thing to include in order to use some header. > >>I don't really care what we actually use. After all, an unsigned 16 bit >>int remains an unsigned 16 bit int whatever we call it. But we should >>settle this at once and make up our minds. >> > I only care for not confusing user-space programmers. Why use a non-standard > type, when a standard one is available? > > Brad > > -- Johann Deneux |