On 2013.01.15 03:26, Jie Zhang wrote: > It's true /W3 is current default setting. But it seems /W4 is not > uncommon for Windows programmers.
Dunno about common/uncommon. You don't happen to have a study at hand to prove your point, do you? If not, I'll continue with the safer bet of assuming that programmers who use the non-default /W4 *choose* to receive extra warnings. > You see libusb uses it itself. That's because, as the Windows backend maintainer at the time, I *chose* to produce these warnings, to help point to potential issues we may want to be alerted to. Thus, I *chose* to get extra warnings, and then *chose* to silence the ones that I (and others) didn't care about, in the context of compiling libusb, and libusb only. There's a world of difference between something that individual users chose and something that is being forced onto everyone, especially if it stems from the *unproven* belief of a single person (so far) that their approach will be 100% safe, even with scenarios and code that they have never seen. Moreover, after I decided to dismiss these warnings, I didn't go around contacting Microsoft to tell them that I believed these C4200 warnings we got on the libusb.h structures were irrelevant and should be suppressed (because, if "safe" usages of zero sized arrays are that easy to identify, as is your postulate for wanting to suppress the warning always, then it shouldn't be that difficult for Microsoft engineers to analyze code and issue that warning only when relevant). On that note, if you are that adamant about saving time for MSVC users as well as these warning being 100% safe in specific situations such as the one libusbx uses them, why then don't you contact the Microsoft MSVC team to ask them to suppress that warning in these situations? If it is such a time waster, you'll have saved a lot more time for a lot more people after you convince Microsoft to update their products according to your recommendations. > When > users turn on /W4, what they want to catch are warnings in their own > code, not those from external libraries. Nu-huh. They want to be alerted to all potential issues, including the ones that may come from external libraries, as there is no guarantee that these are bug-free (they aren't), that their developers have envisioned all possible usage scenarios (they haven't), or that they have been tested for /W4 (we didn't do that for a long time). Thus if, as an application developer, the compiler can alert me to a potential unsafe behaviour, I will very much want it do just that. Then, and only then, I will *choose* whether I want to pay heed to that warning (there might be a good reason it was issued), or silence it if I believe that it is not relevant for the very specific situation I plan to use the library for. As a user, and even more so as a library developer, I'll be darned if I'm gonna blindly trust a library to have thought everything through in order not introduce any issues outside of non-library code. > 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. Unless the compiler developers state the same, you are just expressing your *belief* that the warning does not serve any purpose, something that we have already established you can obviously not demonstrate, and what's more, you are proclaiming that everybody in the world should just share your belief. Don't you see just a little bit of a problem with that? The burden of proof remains on you, not me, one, because I have actually seen real-life cases where seemingly innocuous zero sized arrays introduced hard to figure out issues, and two, because all I have seen so far leads me to think that it will be a lot more damaging for our users if we go with your position, and you end up being wrong, than if we go with my position, and I end up being wrong. > Also note that this is a level 2 warning in C++. So what? I'm also curious why libusb/libusbx C++ users didn't ask us to silence it during all those years then? > In theory, a perfect libusb should be happy with gcc's -pedantic > option. In theory code should be bug free. > 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 Then you are not consistent, and I could really stop right there. > 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. The problem is not how easy it is. The problem is the possible unwanted consequences, which you *choose* to brush aside. > 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." ? As stated above, the question is not how easy or hard it is, so your point is irrelevant. Easy or hard is not what I, or other maintainers, base our decisions on (also, if you want to talk about adding support for another OS, you can also refer to the current WinCE integration, which is what I'm currently working on in between this fruitless discussion --though of course Toby is the one who did the real work there. One could argue that less and less people are going to use WinCE, therefore that it would be easier for us to just tell Toby "thanks, but no thanks". Yet, for the sake of libusbx users, we are integrating support for this OS into libusbx. And right now, after fixing issues with poll_windows.h I need to add more fixes for cygwin, so it's a lot more time consuming than I would have hoped) . Thus, I'll continue to base my decisions not on what's easy/hard, but on what I believe will be beneficial for libusbx users as a whole. My current estimate is that libusbx silencing pedantic warnings is not something that will be beneficial for libusbx users AS A WHOLE (rather than just the users who find themselves annoyed with such warnings). And as a maintainer, it is my responsibility to be cautious about going with only one class of users, such as those who may find pedantic warnings produced by an external library annoying, and alienate another, such as those who may prefer to trust their own judgement and experience with regards to which pedantic warnings may be relevant, rather than the judgement from people, such as you and me, who aren't spending their days developing compilers or analysing heterogeneous code and therefore have limited experience with regards to how relevant a warning actually may actually be. If I balance the expected inconvenience as well as time wastage resulting from going going with either of the conflicting groups above, and with the absence of a statement from someone with in depth experience of problems that may arise from using zero-sized arrays (such as a compiler developer), I see no alternative but to side with the latter group. Again, the potential damage of not siding with this group looks much greater to me than the damage of going with the first group. >> 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. I don't subscribe to this view. When you've spent hours looking for a reason why your code doesn't work, pedantic warnings which you may previously have silenced, start to become real enticing, no matter their location... > I don't see difference between headers from MS ATL and headers from > libusb. Then you haven't read what I said about libusbx users having the ability to use gcc generated binaries with MSVC, and nonstandard extensions meaning nonstandard and potentially incompatible implementations between different compilers. > p.s. I'm glad you are not as worried about the safeness of zero-length > arrays as before. Then there again you are misreading what I wrote. I do not believe that in the context of compiling libusbx, and libusbx only, to produce a library binary, the zero-length arrays warnings are of any significance. Outside of this, it's fog of war, so, for the sake of our users, I'd rather thread carefully. Regards, /Pete ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
