On Wed, Sep 5, 2012 at 5:00 PM, Pete Batard <p...@akeo.ie> wrote:
> This is #26:
> https://github.com/libusbx/**libusbx/issues/26<https://github.com/libusbx/libusbx/issues/26>,
> but doesn't include BOS/EP Companion.
>
> Note that the proposed patch fixes libusb_config_descriptor to use
> bMaxPower, as it is labelled in the specs, rather than MaxPower => this can
> break the compilation of existing applications.
>
> Now, the way I see it is:
> - Not many people use are likely to use the MaxPower attribute in their
> apps
> - We're not breaking linking to the library
> - The few people who use MaxPower should easily be able to figure out why
> they get a compilation error and fix it
> => I'd like to push for this change as I see it low impact, despite
> affecting the API. But I'm ready to hear good arguments against the
> MaxPower -> bMaxPower change.
>
> I also took the opportunity to update the copyright in our most public
> header, as we might as well promote libusbx there.
>
I don't think you should break existing code until libusbx 2.0. I think
you should add:
#define MaxPower bMaxPower
along with a deprecation notice for MaxPower.
You could also precede the #define with an #ifdef MaxPower and emit an
error message, but that shouldn't be a problem as existing code would
already be working with MaxPower defined as something else.
The #define would be removed for libusbx 2.0.
Orin.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
