7 ms·

> and the compiler doesn't even warn you that size is bigger than x That's not true tho, compiler with reasonable flags set will definitely warn you and if you

> and the compiler doesn't even warn you that size is bigger than x That's not true tho, compiler with reasonable flags set will definitely warn you and if you really don't like this kind of code you can force compiler to issue an error instead

simias 5y ago
What flags you have in mind? Because this code doesn't generate any warning with GCC 11.1.0 with -Wall -Wextra: int main(void) { int some_int = 1234567; char c = some_int; return c; }
- ridiculous_fish 5y ago
  -Wconversion will do it.
- aaronmdjones 5y ago
  -Wall -Wextra -Wpedantic does not enable all diagnostics. This is GNU's idea of "all". Contrast to Clang's -Weverything, which will.
  - 130e13a 5y ago
    keep in mind though that -Weverything is not intended to be used in production: https://quuxplusone.github.io/blog/2018/12/06/dont-use-weverything/ https://quuxplusone.github.io/blog/2018/12/06/dont-use-wever...
    - account42 5y ago
      -Weverything is great for CI though, in compination with lots of -Wno-... flags to disable warnings you don't want. Instead of having to manually look out for new warning flags you will get all automatically.
      - aaronmdjones 5y ago
        Yep, this is what I do; throw in -Weverything followed by a few things like -Wno-packed -Wno-padded -Wno-unused-parameter.
  - rocqua 5y ago
    The reason for this decision is so that compiler upgrades with -Wall and -Werror don't break builds. I can see the reason behind it, but I feel that this behavior is something you opt into when you use -Werror.
    - derefr 5y ago
      > The reason for this decision is so that compiler upgrades with -Wall and -Werror don't break builds. It feels like the "right thing" here would instead be for the compiler to allow build scripts to reference a specific point-in-time semantics for -Wall. For example, `-Wall=9.3.0` could be used to mean "all the error checks that GCC v9.3.0 knew how to run". Or better yet (for portability), a date, e.g. `-Wall=20210720` to mean "all the error checks built into the compiler as of builds up-to-and-including [date]." To implement this, compilers would just need to know what version/date each of their error checks was first introduced. Errors newer than the user's specifier, could then be filtered out of -Wall, before -Wall is applied. With such a flag, you could "lock" your CI buildscript to a specific snapshot of warnings, just like you "lock" dependencies to a specific set of resolved versions. And just like dependency locking, if you have some time on your hands one day, you could "unlock" the error-check-suite snapshot, resolve all the new error-checks introduced, and then re-lock to the new error-check-suite timestamp.
      - HanyouHottie 5y ago
        MSVC has this[1]. .NET code analyzers are also versioned[2]. [1]:https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warnings-by-compiler-version https://docs.microsoft.com/en-us/cpp/error-messages/compiler... [2]:https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview#latest-updates https://docs.microsoft.com/en-us/dotnet/fundamentals/code-an...
      - antoinealb 5y ago
        I think it might be more of an headache: what if somebody fixes a bug in an analyzer so that it catches things it used to miss ? Should it be a breaking change ? Personally i would vote for "Wall with Werror" means no guarantee for your build.
  - lazide 5y ago
    It seems though that the point is made, right? Even 'good' approaches miss on what should be a clear 'whoa, are you sure?' type warning. There are a lot of footguns wandering around in C/C++ land.
    - BoorishBears 5y ago
      No, the point was you want don't get a warning and it will silently wrap. You can scroll up if you've forgotten. And it is false. My default configuration C++ project created in Clion shows it very clearly, and even pesters to use int32/int64 over int/long. But as usual the default fallback when you're wrong about C++ is "uh yeah but lotta footguns amirite" As if there aren't enough that we need to start making them up...
      - opheliate 5y ago
        And yet RedHat's recommended compiler flags for GCC [0], for example, do not appear to catch the wrapping assignment in the above example code. 0: https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc https://developers.redhat.com/blog/2018/03/21/compiler-and-l...
        BoorishBears 5y ago
        Ah yes, of course the goalpost was "you need to customize your settings to catch it" above. Now that the default in the most beginner friendly of IDEs catches it, the goalpost is "my pet source of customization designed with C++98 in mind doesn't catch this" Of course, even your pet source of customization caught up: https://developers.redhat.com/blog/2021/04/06/get-started-with-clang-tidy-in-red-hat-enterprise-linux https://developers.redhat.com/blog/2021/04/06/get-started-wi...
        lazide 5y ago
        If said beginning friendly IDE is used by only a couple percent of the ecosystem, it seems disingenuous to use it as proof this isn't a problem in this context?
  - gumby 5y ago
    > This is GNU's idea of "all". Unfortunately, over the years people baked the semantics of -Wall into their builds so new diagnostics could not be added to that flag. And clang’s -Weverything shows how the opposite can fail as well
    - not2b 5y ago
      There are some very wrong-headed warning options in gcc, such that turning them on and avoiding getting them will make your code worse. So -Wall means 'all recommended warnings'. Also there are some warnings that won't be produced if you compile without optimization, because the needed analysis isn't performed.
      - account42 5y ago
        And yet we have things like -Wmaybe-uninitialized in -Wall which by definition will occasionally warn on perfectly good code.
- kllrnohj 5y ago
  Clang-tidy has a check for it: https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.html https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidel...
- rualca 5y ago
  >What flags you have in mind? -Wconversion https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html This is common knowledge for ages. Any cursory Google search returns countless answers. Take this post made over a decade ago. https://stackoverflow.com/questions/1730255/gcc-shouldnt-a-warning-be-issued-when-assigning-an-int-to-a-char https://stackoverflow.com/questions/1730255/gcc-shouldnt-a-w...
- stjohnswarts 5y ago
  -Wconversion will catch this
tialaramex 5y ago
Fair point although it seems "reasonable" varies from one platform to another, it doesn't warn out of the box for me but people have reported MSVC gets warnings here.

simias 5y ago

What flags you have in mind? Because this code doesn't generate any warning with GCC 11.1.0 with -Wall -Wextra: int main(void) { int some_int = 1234567; char c = some_int; return c; }

ridiculous_fish 5y ago
-Wconversion will do it.
aaronmdjones 5y ago
-Wall -Wextra -Wpedantic does not enable all diagnostics. This is GNU's idea of "all". Contrast to Clang's -Weverything, which will.
- 130e13a 5y ago
  keep in mind though that -Weverything is not intended to be used in production: https://quuxplusone.github.io/blog/2018/12/06/dont-use-weverything/ https://quuxplusone.github.io/blog/2018/12/06/dont-use-wever...
  - account42 5y ago
    -Weverything is great for CI though, in compination with lots of -Wno-... flags to disable warnings you don't want. Instead of having to manually look out for new warning flags you will get all automatically.
    - aaronmdjones 5y ago
      Yep, this is what I do; throw in -Weverything followed by a few things like -Wno-packed -Wno-padded -Wno-unused-parameter.
- rocqua 5y ago
  The reason for this decision is so that compiler upgrades with -Wall and -Werror don't break builds. I can see the reason behind it, but I feel that this behavior is something you opt into when you use -Werror.
  - derefr 5y ago
    > The reason for this decision is so that compiler upgrades with -Wall and -Werror don't break builds. It feels like the "right thing" here would instead be for the compiler to allow build scripts to reference a specific point-in-time semantics for -Wall. For example, `-Wall=9.3.0` could be used to mean "all the error checks that GCC v9.3.0 knew how to run". Or better yet (for portability), a date, e.g. `-Wall=20210720` to mean "all the error checks built into the compiler as of builds up-to-and-including [date]." To implement this, compilers would just need to know what version/date each of their error checks was first introduced. Errors newer than the user's specifier, could then be filtered out of -Wall, before -Wall is applied. With such a flag, you could "lock" your CI buildscript to a specific snapshot of warnings, just like you "lock" dependencies to a specific set of resolved versions. And just like dependency locking, if you have some time on your hands one day, you could "unlock" the error-check-suite snapshot, resolve all the new error-checks introduced, and then re-lock to the new error-check-suite timestamp.
    - HanyouHottie 5y ago
      MSVC has this[1]. .NET code analyzers are also versioned[2]. [1]:https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warnings-by-compiler-version https://docs.microsoft.com/en-us/cpp/error-messages/compiler... [2]:https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/overview#latest-updates https://docs.microsoft.com/en-us/dotnet/fundamentals/code-an...
    - antoinealb 5y ago
      I think it might be more of an headache: what if somebody fixes a bug in an analyzer so that it catches things it used to miss ? Should it be a breaking change ? Personally i would vote for "Wall with Werror" means no guarantee for your build.
- lazide 5y ago
  It seems though that the point is made, right? Even 'good' approaches miss on what should be a clear 'whoa, are you sure?' type warning. There are a lot of footguns wandering around in C/C++ land.
  - BoorishBears 5y ago
    No, the point was you want don't get a warning and it will silently wrap. You can scroll up if you've forgotten. And it is false. My default configuration C++ project created in Clion shows it very clearly, and even pesters to use int32/int64 over int/long. But as usual the default fallback when you're wrong about C++ is "uh yeah but lotta footguns amirite" As if there aren't enough that we need to start making them up...
    - opheliate 5y ago
      And yet RedHat's recommended compiler flags for GCC [0], for example, do not appear to catch the wrapping assignment in the above example code. 0: https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc https://developers.redhat.com/blog/2018/03/21/compiler-and-l...
      - BoorishBears 5y ago
        Ah yes, of course the goalpost was "you need to customize your settings to catch it" above. Now that the default in the most beginner friendly of IDEs catches it, the goalpost is "my pet source of customization designed with C++98 in mind doesn't catch this" Of course, even your pet source of customization caught up: https://developers.redhat.com/blog/2021/04/06/get-started-with-clang-tidy-in-red-hat-enterprise-linux https://developers.redhat.com/blog/2021/04/06/get-started-wi...
        lazide 5y ago
        If said beginning friendly IDE is used by only a couple percent of the ecosystem, it seems disingenuous to use it as proof this isn't a problem in this context?
- gumby 5y ago
  > This is GNU's idea of "all". Unfortunately, over the years people baked the semantics of -Wall into their builds so new diagnostics could not be added to that flag. And clang’s -Weverything shows how the opposite can fail as well
  - not2b 5y ago
    There are some very wrong-headed warning options in gcc, such that turning them on and avoiding getting them will make your code worse. So -Wall means 'all recommended warnings'. Also there are some warnings that won't be produced if you compile without optimization, because the needed analysis isn't performed.
    - account42 5y ago
      And yet we have things like -Wmaybe-uninitialized in -Wall which by definition will occasionally warn on perfectly good code.
kllrnohj 5y ago
Clang-tidy has a check for it: https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.html https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidel...
rualca 5y ago
>What flags you have in mind? -Wconversion https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html This is common knowledge for ages. Any cursory Google search returns countless answers. Take this post made over a decade ago. https://stackoverflow.com/questions/1730255/gcc-shouldnt-a-warning-be-issued-when-assigning-an-int-to-a-char https://stackoverflow.com/questions/1730255/gcc-shouldnt-a-w...
stjohnswarts 5y ago
-Wconversion will catch this

tialaramex 5y ago

Fair point although it seems "reasonable" varies from one platform to another, it doesn't warn out of the box for me but people have reported MSVC gets warnings here.