On 2012.09.06 19:51, Orin Eman wrote: > On Thu, Sep 6, 2012 at 11:28 AM, Hans de Goede <hdego...@redhat.com > > 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
That's ugly and IMO that's pretty much stating "even obvious mistakes are OK to leave in". Therefore I don't agree with that approach. If you are serious about following the specs, then you shouldn't keep obvious erroneous deviations from the specs. Instead, you should address them. Libusb and libusbx made the decision to follow the USB specs, up to the designations of the various attributes that we publicize in the header. And the real problem is someone screwed up when they wrote the libusb header: They should have used bMaxPower (this is not a new USB 3.0 designation - bMaxPower is what's in the 2.0 specs, and I haven't checked 1.0), but they didn't. So that's what we *fix*. And yeah, because we're dealing with a library that can be shared, it's going to be an annoyance, but you're always gonna end up annoyed when someone fixes a mess. We screwed up, and we're sorry, but to be credible with regards to our effort, we also need to stick to the specs. And just like specs come with errata that specs users are supposed to follow, and that may very much contradict earlier data, we should be able to produce our own erratas through fixes. I.e. "We told you to use MaxPower, but that was a typo. If you care about the USB specs as much as we do, then you should switch to using bMaxPower and ensure that the library you link against also uses bMaxPower. We're very sorry, but shit and breakage happen, that need to be fixed." Thus, if people using MaxPower feel strongly enough about not having to modify their software/tell their users that they'll need to ensure they use 1.0.13 or later with the (hopefully) handful of applications that use MaxPower, my advice will be to link statically for a while. Now, if there's a majority vote to have the anonymous union, I'll go with the majority (but then I'll ask you to submit a patch proposal on top of the v2 for copyright that I'm going to post shortly, especially if you want me to check that it works for Windows before release). But I think that's a poor decision, and I'll always have second thoughts about established apps that have no flexibility whatsoever to handle errata: We're not trying to break the API because we like it. Instead, we're very much fixing an API that was broken. And, once again, keeping the correct along with the incorrect doesn't seem like the proper way to go for me. Besides, I'm ready to bet that there aren't gonna be that many people that are going to be inconvenienced by this, and if we keep MaxPower as fair game, we're likely to get a lot more people annoyed when we eventually remove it. Alternatively, we also can bump the next version to 1.1.1, because of the API breakage, and declare the 1.0 API incompatible with 1.1, which is what we'd do if we went with the proposal of waiting for 2.0 to introduce that fix. Regards, /Pete ------------------------------------------------------------------------------ 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
