Hi Pete, On Mon, Jan 14, 2013 at 4:33 PM, Pete Batard <p...@akeo.ie> wrote: > OK, let's refocus the debate to try to make the situation more clear to > everybody then. > > The first thing I need to point out, which I think may help > understanding what we are really dealing with here, is that the 4200 > warning is only produced when compiling libusbx-based code with /W4 (the > highest warning level for MSVC, which I would say is roughly equivalent > to -pedantic). But /W4 isn't the default warning level Microsoft sets a > project to when it is created. Please see [1], for an indication of > these warnings only needing to be silenced after we switched to the non > default /W4 warning level. > > In other words, I could sum up what we are trying to accomplish here as > equivalent to silencing the similar warning gcc issues when compiling in > pedantic mode (which I guess, if we agree this is something we want to > do for MSVC, would also have to be carried out for gcc -pedantic then, > as well as any extra warning we get in pedantic mode). > > My take then is that: > 1. Because it isn't the default warning level, most libusbx users will > not use /W4 and therefore not see that warning > 2. If they choose to use /W4, it should also fall on them to silence any > extra warnings they get there. > > Thus, I could say it is only an annoyance for people who deliberately > chose to be annoyed by turning their warning levels to pedantic (that > is, unless later versions of VS set /W4 as the default level which I > don't think they do). > It's true /W3 is current default setting. But it seems /W4 is not uncommon for Windows programmers. You see libusb uses it itself. When users turn on /W4, what they want to catch are warnings in their own code, not those from external libraries. If every library does the same thing as libusb, /W4 will become useless because the warnings the users care about will be hard to see from all the noises from external libraries.
Also note that this is a level 2 warning in C++. In theory, a perfect libusb should be happy with gcc's -pedantic option. But we live in the reality. Try to compile libusb with -pedantic and see how many errors you get. Fixing them will not be a small task. I will not ask for that if I don't want it or don't have a patch to fix it. > But let me also elaborate on the other concerns I have: > > 1. This would be the very first warning we choose to disable in our > header, something I don't believe we have done for any other platform, > and I have reasons to fear we may open a pandora's box, where every > single libusbx users out there can point to this precedent and say > "yeah, if libusbx could remove that other warning I get that annoys me, > because I don't think it will ever be relevant to anyone, that'd be > great..." > Don't let a hard problem stop solving a easy problem. Assume a user requests adding support for a host OS, which is very easy to do. Will you reject it and say "I will not allow this even it's easy to do, because someone else will ask for support for another OS, which might be very hard to add." ? > 2. Non-standard exceptions means non-standard implementation, i.e. every > compiler is free to implement that extension in whichever way they want. > My problem with that is that we have DLL interchangeability, which means > that someone may use a gcc generated DLL (using MinGW) in their MSVC > projects. We even publish such DLLs in our downloads. Of course you may > counter: "how likely is it that gcc and MSVC would implement zero sized > arrays in a manner that's incompatible?" > Unfortunately, they do, and I've had first hand experience of that with > libcdio (you were looking for an example to justify my concerns - see > [2]), when I discovered that in the Microsoft world, an union of > zero-sized arrays is not zero bytes as expected (and as is the case for > GNU), but one byte. I don't remember how much time I spent figuring out > that issue, but I don't think it was less than a couple hours. Now, I > don't think having the zero-sized array warning would have helped me > much (I think it was disabled in the project, as with libusbx, and I'd > probably have ignored it otherwise), but I feel it may have helped others. > No, it will not in most cases, as in your case. A warning is only helpful when its reported location is exactly where the error happens. Otherwise, it helps little or even misleading. > 3. Of course, as per the example you pointed out, MS will have no choice > but to disable a warning introduced by their header when compiling code, > because these headers come from the compiler itself, so it wouldn't look > good on them at all (plus they don't have to care about cross-platform > usage of this header, where different compilers interpreting the header > may implement nonstandard features differently - whereas we do). So > while I'm sure you will disagree, I'm not seeing "looking good when > users choose to go with pedantic options" as a a concern libusbx should > have, unless we do that across the board for all compilers, and not just > MSVC. > I don't see difference between headers from MS ATL and headers from libusb. It's a good practice not to show user warnings from library headers. > I could elaborate some more, but I too feel the discussion has been > going long enough. But to sum up the situation: "Do we want to silence > warnings that are only issued in pedantic mode (and that may not be that > innocuous in cross-platform usage) in the libusbx header?" > Yes if you can. If you cannot for all platforms, do it for some platforms for which you can. Making some users happy is better than making no one happy. p.s. I'm glad you are not as worried about the safeness of zero-length arrays as before. Regards, Jie ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
