Re: [Libusb-devel] _devid_t and _device_t and a bit of void

[frits v. <fr...@so...>]

Michael Bender wrote:

> Well, in all the years that I've been writing C code (since 1982),
> I have never *once* looked at the sources for libc, and yet, by
> some magic process known only to K&R, I have managed to write a
> lot of code, some broken, some not-so-broken, debug the same and
> use/ship the resulting mess without needing to have a look at the
> library sources.

you are obviously a better programmer than I ever was. I often had to
look into library code because I could not figure out why my program was
coredumping


> 
> If a library is properly documented (and assuming that the library
> implements the documented behavior), then why do you ever need to
> look at the sources of the library?
> 

because it coredumps inside the library

> A library very often has internal data that it uses for it's own
> processing purposes. Sometimes, the library needs the state to
> be saved by the application for subsequent library calls to work
> properly, but that's *all* the application is required to do, save
> the state (via a void * perhaps), not to go in there and muck
> around with the library's internal state. The application is not
> "smarter" than the library, and it has absolutely no business
> screwing around with private library data.
> 

libusb's state is all in the libusb handle

>>> libusb should ideally never coredump.
>> The library is not distinct from the application. If there is a
>> client/server system somewhere in the background that's all fine and
>> well, but a programming library should not try to hide useful state
>> from the programmer.
> 
> That's a cop-out answer. libusb should ideally never coredump due to
> internal programming errors or due to the application manipulating
> internal library state when it has no business doing so. Back to my

exactly.
an app should never be able to change private data without the
implementation knowing about it

> libc example - how many times have you ever had libc coredump other
> than when you have fed it garbage?
> 

well, IIRC, some libc functions blow up on NULL pointers

>>>> Ouch no this is the opposite of what I would like to see. Just let
>>>> the pointer serve as the hash?
>>> you lose sanity checking then
>> That's fine. I'm willing to sacrifice this isolation for the huge
>> increase in ease of use.
> 
> I don't get it - what's the ease of use issue you're talking about
> here? Why do you (as an application writer) care about what that
> pointer/void */object handle/whatever contains? All you should care
> about is what it represents.
> 

yes, busid, devid, handles are just tokens and they are unique over the
life of the application

> 
>>>> I don't think the library should bother with trying to stop it,
>>>> since guarantees can not be made.
>>> agreed but the more that libusb can detect, the easier for the app
>>> writer.
>> Not really, since the library can not tell the app writer what was
>> actually intended instead of the erroneous id.
> 
> That's still better than the library scribbling all over memory or
> doing random I/O to the device because we didn't build in enough
> sanity checking in order to make things "easier" for the application.
> 

yup

libusb will validate all the arguments before doing anything.

cheers

fritS