On 2012.09.15 11:42, Hans de Goede wrote:
> Not sure if we really need the last 4 bytes
The last word is the whole point. If we go with major minor only (here 1
and 0), this change is fairly useless for the bMaxPower issue, as pre
and post API change will have the exact same value.
Or maybe you mean major + minor + micro (such as 0x01000D for 1.0.13)? I
can go with something like this if there's a majority vote for it, but
I'd still would prefer a value that gets increased in-between releases,
for every API change, as some people will be using git.
>> Otherwise, for the bMaxPower update, my current preferred proposal
>> would be to have user copy/paste the new libusbx descriptor structure
>> as is, use that in their app exclusively and then use a cast.
>
> I'm strongly against suggesting our users to do something like that,
> instead lets
> just give them a version define to check against.
That was an otherwise, i.e. "if we don't provide an API version define,
which is also my preferred option, then the safest way I see to address
the issue is with struct redefine and cast"
On 2012.09.15 09:34, Ludovic Rousseau wrote:
> I realy do not like this idea. Structures defined by the API should
> not be redefined by the application. That is the source of more
> problems later.
We've been through that. This was a typo introduced in libusb that will
force us to deviate from our goal of adhering as much as we can to the
USB specs if we preserve it (and make people wonder why we deviated).
IMO, errors that are being preserved for historical reasons ("we've
always been doing it that way, even if we know that it's wrong, so we're
not going to change now") is not something we should strive for. If we
do let customs trump logic, we'll open Pandora's box with a precedent.
> I also submitted a new patch athttps://github.com/libusbx/libusbx/pull/44
Applied and pushed. Thanks.
/Pete
------------------------------------------------------------------------------
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
