On 2013.01.13 18:17, Jie Zhang wrote: >>> But this warning is introduced by libusb, not by user >> >> Not really. The warning is introduced by the compiler as a result of >> libusbx using zero sized arrays, which may *or may not* be OK with >> regards to what the user is planning to do, to which we have no insight on. >> > The compiler reports this warning because the code is written in that > way. We say the source code causes a warning, not the compiler causes > a warning.
Except if we use gcc in its usual non pedantic mode, we don't get that warning. So I stand by my claim that the warning is a compiler item. Microsoft chose to have their compiler output that warning by default. Others compilers do not. IMO, that makes it a compiler issue rather than a libusb.h one, in that, if you don't want to see that warning by default, you might very well use a different compiler such as MinGW or cygwin, and you won't get it. But anyway, that's a minor point, so if you want to say that the warning is introduced by libusb, fine with me. >>> so we should >>> hide from user. And we know this piece of code is safe, so we can >>> disable the warning. >> >> I disagree. We have no way of "knowing" that the code is 100% safe. The >> only thing we are assuming is that the using zero-sized arrays should be >> OK when compiling our library using the MSVC compilers we support, and >> therefore we disable the warning there. > > That's actually what I mean when I say "this piece of code is safe". The problem I have is that the libusb.h header is not used to compile our code only. It is also used to compile user code, whose safety with regards to zero sized arrays we cannot assert. I still have not seen any convincing argument that these users will never want to be alerted that libusb.h uses nonstandard extensions, ever. Now, if there's a majority on this list that says "yeah, we don't think any libusbx user will care about that warning, ever", then I'll follow suit. But I'm still not convinced this is the right decision. >> "Knowing" that zero-sized arrays will be 100% safe when used with code >> that we didn't write ourselves, and MSVC compilers that aren't under our >> control, is something that we would need to prove, which I don't think >> you or anyone can do. > > Sorry, I didn't say that we could use > > #pragma warning( push ) > > #pragma warning( pop ) > > to make > > #pragma warning( disable : 4200 ) > > disable warning C4200 only for that zero length array in "struct > libusb_transfer". Other code will still get the warning if user want. Well, even if we do it that way, we may still have issues with data interchange, so I don't like the idea of having compiler specific #ifdefs in a public header when they serve a dubious purpose that we can't rule out will not have unintended consequences for our users (having to silence a warning is not the end of the world, and, provided that the warning does indeed serve no legitimate purpose, it will not affect the quality of the code you compile. So why libusbx should suddenly devote resources silencing this warning is a bit beyond me - and if we do so, shouldn't we also silence the same warning when gcc is used in pedantic mode?). > I don't think so. I believe the main purpose of this warning is to > alert user that the code uses a non standard compiler extension, which > is usually useful for porting. Somehow, I don't think Microsoft is that interested in alerting users who want to port code to another platform (If they care about porting, they're doing a darn good job hiding it, especially with their official refusal to make their C compiler C99 compliant), so I'm not exactly convinced that your explanation is the right one. Unless we get an official answer from Microsoft on that one, we can only make assumptions, such as the one you make above, but without any means of proving them. And that's not really something I can rally with. > Compiler warnings have different > purposes. Some warnings alert user that the code might not run > correctly. Some warnings, like this one, don't. I wish I could be as confident as you are with regards to the intent of that warning. Again, I am not. > We didn't build the compiler, but we should > trust the compiler, at least when its manual says it supports > zero-length arrays as an extension. Otherwise, we'd better stop using > that compiler. That's an interesting statement. If we trust the compiler, why shouldn't we trust that the warning it produces might be something we want to relay to our users as well? Either we trust the whole of the compiler, including the part that issues warnings, or we don't. I'd rather leave our users decide what they want to do with a standard compiler warning than make that decision for them. > > The above assume libusb.h is used in C program. When zero-length > arrays are used in C++, MS compiler reports a level 2 warning, which > indicates the use of extension could cause error: > > libusb.h(983): warning C4200: nonstandard extension used : > zero-sized array in struct/union > Cannot generate copy-ctor or copy-assignment operator when > UDT contains a zero-sized array > > If we use the method mentioned in > <http://stackoverflow.com/questions/3350852/how-to-correctly-fix-zero-sized-array-in-struct-union-warning-c4200-without>, > we can also disable warning for C++. Well, while I'm not adverse with trying to help C++ users if zero sized arrays may be an issue for them as well, I'm not sure I want to trust a solution that starts with: "If you still want to be able to compile this in C, then you must resolve the warning by closing your eyes: silent that specific warning." > It is not the purpose of this warning to catch such programming error. > If a user wants to exchange data between his program and libusb, the > user should Yeah, the user "should" look at the data. The user "should" also write bug free code and they also "should" read the documentation always. Personally, I'm a lot more confident assuming that not all users will do just that, and therefore leave provisions in libusbx to also take care of these cases as well. > If the user uses 1 sized arrays instead, > he/she should have noticed the zero-length array. See above. > Sorry, I cannot prove a program is bug-less. What I can say is this > extension is supported officially by MSVC for a long time. Yes. But it is supported with a warning, so we shouldn't declare it as innocuous. > I'm confident that compiler is mature for this feature. That's what I'd tend to believe as well. But I'd hate seeing someone come with a scenario that we didn't anticipate, proving the above wrong. > As I said, extensions should be treated as normal language feature if > the compiler supports it. And as I said, warnings issued by compiler should not be silenced unless we are 100% positive that there's never going to be a scenario where a user might have wanted to be alerted to them. Also, I have to wonder why, if these extensions were to be treated as a normal language feature, and considering that I'm dubious that Microsoft has much concern with portability, Microsoft still decided to issue a warning for them. After all, despite their compiler not being C99 compliant, they don't issue warnings for C99 style comments for instance... > For compilers, like MS compiler and gcc, you can have confidence on > such old extensions. If it causes issue in future, we can deal with it > in future. Sorry, but as a maintainer, I'd rather avoid that for something that I don't see keeping as is as that penalizing for our users. > Adding burdens to current users because of such uncertainty > usually is not good. Please don't equate a warning that, at best, may be seen as a minor annoyance by our users, to a burden. I really still don't get why this silencing of a specific warning is that critical to you, so could you please elaborate on that? I'd really like to understand where you're coming from. Maybe it's an altruistic desire to make libusbx look nicer for MSVC users out there, in which case congratulations, but I can't say I'm entirely convinced this is the case? How would having to silence that warning outside of libusb.h so negatively impact what you are attempting to do? >> Finally, I also fail to see why disabling this warning should be that >> much of a priority. It's not like we're preventing anyone to disable it >> should they choose so, and it shouldn't take an experienced developer >> more than 30 seconds to do just that in their application. >> > It's true. But it's only 30s to do that in libusb, too, which will > save many 30s of many users. But still waste hours for the users who would have preferred to get warning, rather than dig up their code to figure out why it didn't produce the result they expected due to nonstandard exceptions being in use, which they didn't get alerted to because libusb.h took the liberty of silencing a warning for them. I'd rather save time for all potential users collectively, and not just the subset you mention above. This is even more true as nobody bothered to complain about that warning until now. This leads me to believe that, so far, the time they are potentially losing silencing that warning, ifd they decide they want to do that, is not construed as a major matter. Regards, /Pete ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
