13 ms·

Nice summary. Out of curiosity: Why are those warnings not automatically included in "-Wall -Wextra"? Is there any issue with enabling them? Are these somewhat

• ishtu 9y ago
  Clang (since LLVM version 4.4) has flag -Weverything which really reports everything https://www.bignerdranch.com/blog/a-bit-on-warnings/ https://www.bignerdranch.com/blog/a-bit-on-warnings/
  • cpeterso 9y ago
    clang doesn't document the full list of warning flags that it supports, but the clang source code has a list, including the hierarchy of meta flags that enable other flags: https://github.com/llvm-mirror/clang/blob/master/include/clang/Basic/DiagnosticGroups.td https://github.com/llvm-mirror/clang/blob/master/include/cla... http://fuckingclangwarnings.com/ http://fuckingclangwarnings.com/ has descriptions of many of the warnings, but more recent warnings aren't covered because the website hasn't been updated since 2014.
    • zmodem 9y ago
      See https://clang.llvm.org/docs/DiagnosticsReference.html https://clang.llvm.org/docs/DiagnosticsReference.html
      • cpeterso 9y ago
        Thank you! I've never seen that page. It doesn't show up when searching for "clang warnings" in DuckDuckGo or Bing, but I see now that it is Google's result #2. I just found a GitHub repo that lists which warning flags are supported by different versions of clang and gcc: https://github.com/Barro/compiler-warnings https://github.com/Barro/compiler-warnings
  • jordigh 9y ago
    I'm not convinced I want Scott Meyers yelling at me with -Weverything as part of -Weffc++. I think I side with the gcc devs here on not having a flag to enable every possible warning ever.
    • bennofs 9y ago
      You can just use `-Weverything -Wno-effc++` then
    • 2trill2spill 9y ago
      Why not have the flag and not use it if you don't want it? That way other users of gcc who want that flag are not deprived of that feature.
  • spc476 9y ago
    I found -Weverything seriously annoying. Declare a structure, and clang warns about padding bytes being added. Make it a packed structure, and clang warns about the lack of padding bytes. Useless! Okay, I can see the warning on packed structures, as that's usually a compiler extension, but a plain struct? Seriously?
    • 2trill2spill 9y ago
      Then turn off that warning if you don't like/want it.
      • spc476 9y ago
        The point is there's a warning either way. Pack the structure, and you get warnings. Don't pack the structure, get warnings. To me, that's being needlessly pedantic.
    • userbinator 9y ago
      There is also -Wlogical-op-parentheses, which rather condescendingly implies that you don't know the precedence of || vs &&. (The main use of parentheses is specifically to indicate precedence different from the usual, since otherwise they just add noise to the code and reduce clarity.) I half-expect -Warithmetic-op-parentheses or even -Wop-parentheses to show up in some future version of clang... Unfortunately there's no corresponding -Wuseless-parentheses, which if present would truly make -Weverything a "damned if you do, damned if you don't".
    • Too 9y ago
      I think clang added a -Weverything just to prove a point why it's a bad idea to actually contain _all_ warnings in -Wall. As you say, some warnings are contradictory and it's up to the project to decide which one of them is more important.
• wyldfire 9y ago
  It's a design goal to be flag-compatible with gcc, so in general all these warnings are or will be supported in clang.
• jcelerier 9y ago
  > Why are those warnings not automatically included in "-Wall -Wextra"? Is there any issue with enabling them? Are these somewhat experimental? Because tons of people keep complaining "muh my build breaks if they enable new warnings". Dammit, idiots, if your build break there's a good chance your software is already broken too; that's the point of breaking the build: making bugs visible so that you have to fix them.
  • craftyguy 9y ago
    that's a terrible excuse for not enabling them in -Wall. Is there a -Wreally-all?
    • loeg 9y ago
      Clang has -Weverything. GCC doesn't: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66293 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66293
      • jordigh 9y ago
        It looks like -Weverything for gcc would make a lot of code not compile (along with -Werror). For example, it would include -Weffc++, right? Those are warnings if your code just doesn't obey one guy's now-outdated opinions of what C++ should look like. That's what this says at the bottom: https://github.com/Tuplanolla/gcc-weverything https://github.com/Tuplanolla/gcc-weverything
        • jcelerier 9y ago
          > For example, it would include -Weffc++, right? Maybe, but where's the problem ? Just add -Wno-effc++ afterwards.
        • loeg 9y ago
          Yes, -Weverything + -Werror is often a silly combination. That isn't a GCC-specific problem, though. Clang with both flags will fail to compile quite a lot of code, too. As the other reply points out, you can just use -Wno-effc++ on top of -Weverything. You could also avoid that particular problem by not using C++ ;-).
• dmm 9y ago
  > Why are those warnings not automatically included People who do production builds with -Wall and -Werror ruin it for the rest of us.
  • quotemstr 9y ago
    Compilers should at least support -Wall2017 or something then, enabling warnings in existence in that year and failing compilation for years in the future.
    • pbiggar 9y ago
      Yes, this is exactly right. If you want to automatically upgrade a thing, you need a way for them to pin their existing config so it doesn't break. A good analogy here is Stripe's API versioning: they keep making it better, but you're pinned to the version you start with until you upgrade (which you can do selectively).
  • vog 9y ago
    Ouch. In OCaml there is a very simple rule: Development builds run with "-warn-error", which is OCaml-speak for "-Werror". Production builds run without that option - simply because future version of ocamlc might introduce new warnings that would make the build fail. This makes a lot of sense to me. Why did the C/C++ ecosystem adopt a different aprroach to production build compiler options?
    • pm215 9y ago
      There isn't really a single coherent "C/C++ ecosystem", but for your average "build with make" program there isn't really a 'production' vs 'development' build distinction that would be easy to hang this off. (QEMU enables -Werror for builds from a git tree but we had to put a bit of special purpose in our configure script to do that.) You can't tie it to "is this a debug build" because some warnings only appear for optimised builds so ideally you want to have the check for both debug and optimised.
      • 9y ago
• wongarsu 9y ago
  Most of them sound like they might have a large amount of false positives if turned on for an existing code base (a "false positive" in this case would be a case where you would dismiss the warning after investigation). A large amount of warnings that don't point to "actual problems" causes people to ignore or overlook the actually important warnings. (I'm not saying that these warnings are pointless, but you can have a bug-free code base that triggers a lot of these)
  • icebraining 9y ago
    Can't you use pragmas to silence those specific cases?
• gciruelos 9y ago
  some have a lot of false positives (even some in -Wextra have had false positives due to bugs), so if you compile with -Werror (as you should do) it can be troublesome.
• richardwhiuk 9y ago
  I suspect macro expansion causes too many false positives for many of these.
  • throwaway613834 9y ago
    They should allow disabling some of these for macro expansions then.
• coherentpony 9y ago
  Because of -Werror.
• breadbox 9y ago
  > Why are those warnings not automatically included in "-Wall -Wextra"? Not all of them are actually errors, maybe depending on your style. For example, shadowing a variable is a well-defined feature of the C language, and so some code patterns take advantage of that fact. Other people avoid shadowing like the plague.
  • throwaway613834 9y ago
    IMO shadowing is wrong in the same function and needs to be punished :) but "shadowing" other scores like base classes or class members or the is definitely okay, since you should be using a qualifier like foo:: or this-> to access them anyway.
    • jhasse 9y ago
      > you should be using a qualifier like foo:: or this-> to access them anyway. I think a lot of C++ devs will disagree with this. It's also very uncommon from my experience. One could argue that this should be solved by semantic highlighting or naming conventions instead.
      • throwaway613834 9y ago
        Yeah, I would disagree with a lot of C++ devs on this. But I strongly stand by my opinion. First of all, it's not even a substitute. m_foo won't work if it's declared in a class based on a template parameter; you'll still need a qualifier. And suddenly that makes the code inconsistent, which in itself is kind of bad. Inconsistency makes it harder to read code and spot mistakes. And why should how you refer to a variable change based on the mere fact that the class containing it takes a template parameter? Second, there is really no good reason why you should have to change class C { C(int width) : value(width) { } int width; }; to class C { C(int width) : m_width(width) { } int m_width; }; Ambiguity? Not really. If you actually follow the convention of qualifying member variables with this-> or the like, nobody would ever get confused at whether the "x" in x = 1 refers to a local variable or to a member variable. Literally the only reason to do this is laziness in typing, and C++ was most definitely not designed to be the language for saving keystrokes. You just have to get that notion out of your system when using the language; it just leads to worse code (speaking from experience). Furthermore, there is no reason to encode the member-ness of a variable into its name. What's so special about that information? Should we start encoding the access specifiers too (private/public/etc.)? What about whether it's a class member? s_m_priv_width instead of just width? Why can't we just call the variable whatever darn thing it represents? And my tongue is halfway in my cheek here, but this feels akin to naming your American kid AmeriAlex instead of just Alex. What sense does that make? Finally, let's get semantic highlighting out of the way -- it fundamentally cannot with C++ syntax or with the C preprocessor, and it's twice as impossible with the two. It's never clear what m_foo refers to. Is it a global or is it in the base class? If it's in a header file included by two other .c files, and the preceding header files declare different base classes, what color should it have? It would refer to different things (maybe in one case in a namespace, and in another case in a class). Coloring is just an unsolvable problem in this language; it's not reliable in telling you where a variable referred to is declared.
• asveikau 9y ago
  I'll bite. It seems like a number of these would complain about perfectly benign code. Here's an example I can think of: b = (a == 0) ? 42 : 42; A lot of readers are probably thinking this line is absurd and why on earth would a compiler not yell at you and call you a bad human being for writing this? But let's be creative ... What if each of those 42s are expansions of different macros that vary based on an ifdef? You could have one platform or configuration where it expands to ? 43 : 42, and another where it expands to ? 42 : 42. Since the preprocessor does those expansions early, your compiler doesn't know the difference at the time of generating the warning. I just confirmed this in a small program, replacing the first 42 with FOO, the 2nd with BAR, and #defining them both to 42: warn.c:9:23: warning: this condition has identical branches [-Wduplicated-branches] b = (a == 0) ? FOO : BAR; Overall I would say items in this list are not equally bad. Some of them unambiguously you want to flag. Others are things that people might do intentionally.
  • throwaway613834 9y ago
    This is another reason why macros should not be treated or even viewed as source transformation passes. There is information loss involved in that. There's no reason the compiler shouldn't be able to only warn in the absence of a macro expansion.
    • bluetomcat 9y ago
      The compiler passes of both GCC and Clang are aware of macro expansions since they are able to tell you about errors which occur after a macro expansion, i.e. the error messages similar to "... in expansion of macro X ...".
      • throwaway613834 9y ago
        Yeah I'm aware. I'm more referring to the comments here, where people use "this is generated by a macro" as a justification even though that only makes sense if you think of preprocessed code as a separate stage from the actual code, which I'm arguing you shouldn't. That said though, I'm surprised they don't treat it that way for other cases like these?