From: Pete B. <pb...@gm...> - 2011-02-11 11:39:08
|
On 2011.02.11 02:18, Segher Boessenkool wrote: >>>> Overall, I see only gcc bugfixes in the situation your describe: gcc >>>> failed to properly apply a standard, >>> >>> No. The problems are where the compiler didn't diagnose a standards- >>> compliance issue before, and now it does. This is a problem in the >>> libusb code, not in GCC. >> >> No. The problem, as you presented it, is that even if we switched to >> c89, and found that everything was fine with the versions of gcc we test >> with, our users would definitely end up finding newer versions of gcc >> that enforced a stricter, > > That's what I said. Then I'm going to dispute the idea that we're going to get so many bugs reports on C89 breakage from future gcc versions, that we won't be able to address them in a timely manner as they appear. Please understand that I'm not disputing that you may have seen breakage in the past on such matters. But what I strongly doubt that: 1. The ratio of issues will be skewed towards actual breakage rather than warnings, which users can ignore (but chose to report if they so wish) 2. It warrants the need to establish _double standards_ in libusb, with one standard for contributors/libusb-developers and one standard for developer-users. Double standards must be avoided. 3. We need to be proactive about it before we've actually seen whether it actually makes sense to switch our code to c89 (remember, this hasn't been tested at all - we don't have the slightest clue as to the feasibility of such a switch. Personally, I expect to see a flurry of issues, such as the one Michael had with variadic macros support in MSVC6, and I'm very dubious as to switching to c89 being worth the effort - but we can't tell until we try) and have an idea of the actual volume of c89 annoyances reports we get in trac. >> backward incompatible c89. > > Not backward incompatible. The libusb code would be buggy; Yes, it would, because gcc was buggy in that it didn't report libusb C89 compatibility bugs as extensively as it should have. > So a newer compiler can catch more bugs than the older compiler, > while both are perfectly standard compilers (not that anything > will ever implement C to the letter, but heh). That's great then. If newer gcc catches more (libusb) bugs, then why should we attempt to close our eyes on that? Let's say we had an option to force the detection of memory leaks, at no performance cost, in MSVC (NB such an option does exists, but only when using debug system libraries). Should we only enable it for libusb-developers/contributors but not developer-users, because we don't want them to be bothered in case they find a memory leak? Well, if we have bugs in our implementation of the C89 standard, should we not want our users to help us catch them too? Also whatever happened to us upgrading our toolchain/tools on a regular basis? If we do so, most of the issues we'd get reported would come from users with development/yet-to-be-released versions of gcc, i.e., versions where breakage is expected. Once there's an actual gcc release, if we follow the same path as for the git upgrade (where a 3-4 month old version of git is considered in need of an update, as you previously established), then we are very likely to catch C89 issues ourselves, and fix them, before our users even get a chance to see them. I don't really see a problem here then... unless we contradict previous statements with regards to trying to keep our toolchains up to date. > I'm confused now, I thought the thing you linked to was about > shadow warnings in "index". Don't be fooled by the subject. Are we still discussing the claiming of interfaces in this thread? >> The shadow issue was cygwin only, but Peter talks about MSVC6 as the >> main reason to enforce c89. > > Seriously? I'm afraid so. At least that's how I interpreted it at the time. Doesn't mean that I agree with such a switch. > Well, we could always just drop support for a compiler > that is older than the first version of GCC-2.95! Indeed we could. Or not make plans to add support for an OS that's no longer officially supported by its maker (Windows 2000). (To be 100% clear here: I am _not_ advocating removing support for any of the above. As long as it isn't taxing to support, let's support it!) >> Here goes then: >> 1. libusb moves to enforce std=c89 everywhere before Hans comes along >> 2. Hans produces a patch, and, because he can't use named struct >> initializers in Linux, realizes that he also needs to add a >> NULL/skeleton call in the Windows and Darwin backends. >> 3. Patch submitted works. > > And on the other hand: > > -- No one can use e.g. designated initialisers in their backend, > leading to lots of bugs. Yes, as I stated, it's a lose-lose situation. There's no clear winner in doing it one way or the other. >> The current patch _breaks_ libusb compilation and needs fixing. > > No one is disputing that. And *users* never have this pain. Except we have already _seen_ contributors actually feel the pain in having to rewrite a patch, whereas your statement about hordes of gcc users expected to feel the pain is speculation. If we're going to speculate here, then I will speculate that the only pain users are likely to get out of std=c89 are warnings. Very different from actual breakage such as what we've experienced here. But maybe we want to take a vote then: In the _hypothetical_ situation (again, we're not actually advocating this as the moment) where libusb was to enforce -std=c89 on compilation across platforms (and our code had been patched accordingly), who here believes that we are going to see so many reports of future-gcc issues related to C89, that we need to take preventive action? In the end, that's all this aspect of the discussion really boils down to. > I think it's a mistake to want C90 anyway. But for the time > being, the core stuff should compile with<whatever compilers > we support>, so if some of those do not accept all of what we > want to use of C99, we cannot use that in the core parts. > > And it would be good if developers can easily check for that. And I 100% agree with the above statement. If we can make it easy on libusb-developers to check on that (still planning to see how the WDK works in wine, and how straightforward libusb compilation would be, so that I can post a guide or something, as WDK is the best compromise for MSVC), and if in return libusb-developers make a genuine effort to understand that libusb is more than one platform, and that they should therefore attempt to not constrain their testing to a single one, then I'm fine with not trying to restrict the C standard for core, or elsewhere, in any other way than "whatever works across all the toolchains we support". Regards, /Pete |