Hi, On 09/06/2012 08:20 PM, Orin Eman wrote: > > On Thu, Sep 6, 2012 at 3:07 AM, Hans de Goede <hdego...@redhat.com > <mailto:hdego...@redhat.com>> wrote: > > Hi, > > On 09/06/2012 04:35 AM, Orin Eman wrote: > > On Wed, Sep 5, 2012 at 5:00 PM, Pete Batard <p...@akeo.ie > <mailto:p...@akeo.ie> <mailto:p...@akeo.ie <mailto:p...@akeo.ie>>> wrote: > > This is #26: https://github.com/libusbx/____libusbx/issues/26 > <https://github.com/libusbx/__libusbx/issues/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 > > > That was my initial thought to, but MaxPower is too generic of a name to > define IMHO, I would > expect that to cause more problems then it fixes. As said few apps are > expected to use > MaxPower, and fixing those who do is easy, and they will only break at > compilation > time. So I'm with Pete here and suggest to just do the rename, with a > clear warning about > it in the ChangeLog and NEWS files. > > > > Yes the problem is easy to fix - for programmers, but not all that update and > build packages are. > > A preferable (to me) alternative would be an anonymous union, but I was > unsure that all compilers would accept it.
An anonymous union would work for me, but I'm not sure all the compilers we want to support support this, esp. the windows ones may not... Pete ? Regards, Hans ------------------------------------------------------------------------------ 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
