On Sat, Jan 12, 2013 at 6:20 PM, Pete Batard <p...@akeo.ie> wrote:
> On 2013.01.12 03:23, 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.
>> 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".
> "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.
> So, to reiterate what I was trying to say earlier, the Microsoft
> engineers did put a warning when zero-sized arrays are in use for a
> reason, most likely because they have experienced situations where
> zero-sized arrays resulted in issues that developers would need to be
> alerted on. While we have some idea, we do not know precisely what these
> reasons were, therefore I don't think it is safe for us, who didn't
> build the compiler, to assume that for code that isn't under our
> control, those warnings are benign and can safely be ignored.
>
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. Compiler warnings have different
purposes. Some warnings alert user that the code might not run
correctly. Some warnings, like this one, don't. The warning does not
mean using of this extension is not safe. It's legal as long as the
extension is allowed. 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.
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++.
>>> I will assume that the warning is there for a legitimate reason and
>>> therefore that some libusbx users do want to be alerted for a
>>> nonstandard extension used. I think I can see a scenario for it if
>>> they're going to interop with a library or app where 1 sized arrays were
>>> used instead of zero sized arrays, in which case they may get very bad
>>> surprises when using sizeof on the structs they going to interchange,
>>> whereas this is probably what the warning is meant to alert against.
>>>
>> Sorry, I don't understand this part.
>
> I'm just trying to provide an example where someone might be putting a
> library that was compiled with nonstandard C extensions (libusbx) and an
> application or library that uses a stricter C standard together. Most
> likely compilation should fail when libusb.h is parsed, but it may not,
> and if that user, is using equivalent structures that use 1 sized arrays
> rather than zero sized arrays, in order to comply with a more stringent
> C standard, when they try to interchange their 1 sized arrays based
> structs with libusbx's zero sized ones, they may encounter issues.
>
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 at least look at the data structure used in libusb and
write his code accordingly. If the user uses 1 sized arrays instead,
he/she should have noticed the zero-length array. We don't need this
warning to alert him/her.
>> libusb.h is a public header, so this is not an internal affair.
>
> I agree with that. As such, I would state that our goal is to make sure
> that libusbx users are alerted to potential issues.
>
>> As I said above, this piece of code is safe.
>
> Can you prove it?
>
> If you state that the code is safe, then you must be able to demonstrate
> that every single Microsoft compiler a libusbx application can be
> compiled with, and every kind of libusbx application one can think of,
> will not have an issue with zero sized arrays, ever.
> Personally, I don't believe you or anyone can do that, which is why I
> will continue to advise caution.
>
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. I'm
confident that compiler is mature for this feature. Compiler extension
is same as standard language feature. It does not cause more bugs than
standard feature. It's really not necessary to alert user because it's
an extension.
>> We don't need this warning to
>> warn user. As you said, this piece of code is directly under out
>> control, so we have the responsibility to take care of the warning for
>> user.
>
> Not really, what I tried to say is that the libusbx library code is
> under our control, and only that code. But libusbx, and the libusb.h
> header, are meant to be used in applications and with code that are not
> under our control at all, and who might be using our structures in way
> we haven't anticipated.
>
> As such, my opinion is that we should not risk silencing that warning,
> in case we are wrong and it does serve a legitimate purpose that we
> simply haven't foreseen yet, due to lack of experience or imagination.
>
As I said, extensions should be treated as normal language feature if
the compiler supports it.
> I wish I could have your confidence in stating that "the zero sized
> arrays used in the libusb.h header are never going to be an issue with
> MS compilers", but to me that's akin to predicting the future, which is
> a bit too much of a stretch.
>
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. Adding burdens to current users because of such uncertainty
usually is not good.
> 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.
Regards,
Jie
------------------------------------------------------------------------------
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
