Hi Pete,
I think the email has become too long to get the discussion on focus.
So I'm going to summarize your point and my point. If I understand
wrong about your words, please pointing out.
Your point: The C4200 warning given by MS compiler implies the using
zero length arrays is unsafe beside it's a non-standard extension,
although this implication is unsaid in MS compiler's manual. Although
its use in libusb is safe (so libusb disable that warning), it might
cause errors in user's code in future. And it's fairy easy to disable
the warning in user's code, so libusb leaves that warning to alert
user that this zero length array might cause errors in his/her code.
If user doesn't like that warning, he/she can disable it by
himself/herself.
My point (assume libusb.h is used in C code): The C4200 warning given
by MS compiler only means it's a non-standard extension. MS compiler's
manual does not say it's unsafe. Its use in libusb is safe. It's not
likely it will cause errors in user's code. Users will not want or
need this warning. It's easy to disable it in libusb. So let's disable
it in libusb to save users' time.
I'm almost giving up this discussion because it's impossible to prove
using this extension is absolutely safe, i.e. for all supported MS
compilers and for all user code, as you asked. We all know it's
impossible. We all know what it means when we (programmers) say a
piece of code is safe. But I want to try the last time. I just found a
core header in VC has used this extension for many years with C4200
warning disabled. See VC/atlmfc/include/atlcore.h, search for the line
containing "pragma", "warning" and "4200". It exists in VS2005, VS2008
and VS2010. Sorry I have no earlier versions or VS2012. That piece of
code looks like this:
I#pragma warning(push)
#pragma warning(disable: 4200)
struct ATLSTRINGRESOURCEIMAGE
{
WORD nLength;
WCHAR achString[];
};
#pragma warning(pop) // C4200
It seems MS is confident about its compiler on this extension. However
I doubt this will be a good argument since you has less confidence on
MS and its compiler, and you could still say this small piece of code
means nothing for all code.
I will not reply all since I have reiterated my words many times. I
will pick something interesting to comment. See below:
On Sun, Jan 13, 2013 at 3:37 PM, Pete Batard <p...@akeo.ie> wrote:
> On 2013.01.13 18:17, Jie Zhang wrote:
> 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.
>
I'm not sure if the above atlcore.h code is convincing for you or not.
It's convincing for me.
> 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.
>
Run a poll? Just kidding. I don't think it's worth that effort. But if
you do some googling, you will find people asked about why they got
this warning, then someone replied and explained this warning and how
to disable it, then people who asked usually said "thank you". You
will find several questions are about the warning in libusb. That
tells us people either didn't care about this warning, or all they
want was disabling it. But again, these do not represent all
programmers.
> 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
Let's assume your example exists. There is an error happens in user
program as you predicted. Can user easily related the error with this
warning? I'm pretty sure the error will happen elsewhere, sometimes
far far away from the location the warning points out. This warning
will provide very little help to fix such an error. Worse, if user
suspects his/her error was caused by this warning, but actually not,
this warning will cause a much larger cost than without this warning.
If an error happens, which is more possible: it's caused by this
zero-length array or by other things?
> (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?).
>
Why does libusb internally disable this warning for MS compiler but
not for gcc pedantic mode?
>> 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.
I would suggest stop development of libusb and don't make decisions
for uses and let them just use what OS provides. Kidding again. As a
library, we provide a good abstract for users, which provides
convenience for them. Not passing warnings to users who don't care is
one kind of convenience. OK. we came to the core question again: do
libusb users want this warning or not.
>>
>> 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."
>
According to my limited C++ knowledge, that reply is a good one if you
read it to the end. But I could be wrong since I just started using
C++ a few months ago.
>> 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?
>
You might have heard some projects requires zero warnings. I don't
want to say much about the goodness of this requirement, but I think
it's a good practice in programming. I can disable the warning in my
code. But I think it would be better to disable it in libusb, which
will also help other users. But apparently you don't think so.
As a long time free/opensource software user and developer, I like to
help improve the source code I care about. What do you think my
purpose is after I spent so many precious hours in weekend? ;-)
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. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
