On Fri, 10 Apr 2015, Christian Böhme wrote:
> Alan Stern <stern@...> writes:
>
> > > Given that hid_mouse_ignore_list[] actually contains the proper
> > > (USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ISO) pair
> > > as far as I can make out and assuming a properly working compiler,
> > > hid_match_one_id() returns FALSE only if the hdev's members in question
> > > are not properly set up. And I wouldn't know where to look for /that/.
> >
> > You ought to be able to figure out what's going on by adding a few
> > debugging statements in suitable places.
> ^^^^^^^^^^^^^^^
>
> What are those ominous places?
The places where the code sets and tests the HID_TYPE_USBMOUSE flag,
and where it tests for a matching ID. Basically, the places that
affect the thing you want to accomplish.
> > > On a side note, I'm a little surprised that the arguments to …
> > > are not const-qualified, although none of their members are actually
> > > mutated there …
> >
> > That sort of thing happens all the time. People don't remember to add
> > const qualifications because it's not obvious when they _could_ be
> > added,
>
> How can it not be obvious to the author(s) of their own code?
You seem to forget that the kernel was written by thousands of
different people. Even if somebody is familiar with his own code, he
isn't necessarily familiar with code written by someone else.
> Does
> the semantics of the language randomly change when nobody's watching?
That would make computer science a lot more intriguing! :-)
> > the compiler doesn't complain about it,
>
> $ gcc -v
> Using built-in specs.
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --enable-checking=release --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-libgcj-multifile
> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
> --disable-dssi --disable-plugin
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
> --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)
> $ gcc -Wall member.c -o member
> member.c: In function ‘g’:
> member.c:12: error: assignment of read-only location
> $ cat member.c
> struct A {
> int x, y;
> };
>
> void f( struct A * a )
> {
> a->x = 1;
> }
>
> void g( const struct A * a )
> {
> a->y = 2;
> }
>
> int main( int argc, char * argv[] )
> {
> struct A a;
>
> f(&a);
> g(&a);
>
> return 0;
> }
>
> This one does. And I'm positive all newer versions do, too.
Your example doesn't contradict what I said. Go back and reread my
comment, and then consider this example instead:
$ gcc -Wall const-test.c -o const-test
$ cat const-test.c
const char *y;
void a(char *x)
{
y = x;
}
int main(int argc, char **argv)
{
a("hello");
return 0;
}
The function a() makes no assignments through x. Therefore it could
and should have been defined as "void a(const char *x)" -- but the
compiler did not complain.
> > and it doesn't make much
> > difference anyway.
>
> I disagree. It's precisely what aids in avoiding situations like the
> current one where nobody seems to know what's going on anymore. That's
> what const-qualifications where invented for (if there is such a thing).
> Somewhere a member's value is changed where it shouldn't. How can that
> not make a difference?
You might be able to find a few cases where the kernel code changes a
value that should have been declared const, but not many. Like I said
before, the real problem is that there's no penalty if you forget to
mark something as const when the code _doesn't_ change it.
If you want, you could submit a series of patches that do nothing but
add const declarations in the places where they are missing.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
