4 ms·

I don't get your point at all. C++ has different casting operators (static_cast, const_cast, reinterpret_cast) that are strictly safer than C-style casts. Also

I don't get your point at all. C++ has different casting operators (static_cast, const_cast, reinterpret_cast) that are strictly safer than C-style casts. Also, let's not forget that implicit casts between unrelated pointer types is only a warning in C. Fortunately, modern C compilers started treating it as an error by default because it caused so much harm: https://gcc.gnu.org/gcc-14/porting_to.html https://gcc.gnu.org/gcc-14/porting_to.html. In C++ this was always a compiler error.

1718627440 5mo ago
> implicit casts between unrelated pointer types is only a warning in C A warning in C has the meaning of a "stern warning" aka. "That very much won't work, I warned you!". An error means, "I literally, don't what you mean". Also as far as I know, the C standard only talks about diagnostics.
- spacechild1 5mo ago
  You are right that the C standard only talks about diagnostics, but this doesn't change the fact that implicit casts between unrelated pointer types are not treated as hard errors.
  - 1718627440 5mo ago
    That's what I addressed in the first paragraph, a warning in C is a serious thing, not just some random nuisance.
    - spacechild1 5mo ago
      Ok, but then compilers should really throw errors for these diagnostics by default. Why lump serious issues like incompatible pointer casts together with benign things like uninitialized variables? (Another pet peeve of mine is that missing returns in functions is not considered a hard error. GCC 16 does not even issue a warning by default when compiling C code, which is just crazy. "-Werror=return-type" is the first thing I do in every new C or C++ project. I don't understand how this is still not the default...)
      - 1718627440 5mo ago
        > Ok, but then compilers should really throw errors for these diagnostics by default. That's because the default mode for compilers is to just shut up and compile this throw away code. Programmers know that you are expected to turn the warnings on and also nobody is manually invoking compilers directly. The default for build systems is often "-Wall -O2" anyway. Personally I prefer the status quo, I hate tools, that I just invoke and they start spamming my terminal. "Like, I know, that there will be issues, that's why I'm using you, but you don't need to tell me until I told you what exactly you are supposed to report me. Don't spam me until I ask you." > Why lump serious issues like incompatible pointer casts together with benign things like uninitialized variables? ?? Uninitialized variables are also serious issues and also undefined behaviour. If anything they're more serious, because for pointer casts, it is likely that the types are compatible, but the compiler just doesn't know it, while truly uninitialized variables are always a real error. For the latter, the issue is rather, that the compiler often can't proof whether the variables are actually uninitialized. That's why it is more likely to meet a "maybe-uninitialized", a true "uninitialized" is rare in the wild.
        spacechild1 5mo ago
        > That's because the default mode for compilers is to just shut up and compile this throw away code. That's just not true. Compilers do issue certain warnings by default and they even treat some warnings as errors. See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > ?? Uninitialized variables are also serious issues and also undefined behaviour. Oh my, I meant to write "unused variables" facepalm. Uninitialized variables are of course a serious issue. So back to my original point: you said that warnings in C are always a serious thing, but that's not really true. Warnings can range from more or less harmless to very serious. In fact, compilers recognize this issue by upgrading certain warnings to errors by default. See again my link to the GCC 14 post: https://gcc.gnu.org/gcc-14/porting_to.html https://gcc.gnu.org/gcc-14/porting_to.html.
        1718627440 5mo ago
        > That's just not true. Compilers do issue certain warnings by default and they even treat some warnings as errors. Because some warnings are just believed to be more serious, than others. > In fact, compilers recognize this issue by upgrading certain warnings to errors by default. Which I interpret as a culture shift, due to people complaining about it and also because the contemporary meaning and expectation of warnings for programming languages has shifted.

1718627440 5mo ago

> implicit casts between unrelated pointer types is only a warning in C A warning in C has the meaning of a "stern warning" aka. "That very much won't work, I warned you!". An error means, "I literally, don't what you mean". Also as far as I know, the C standard only talks about diagnostics.

spacechild1 5mo ago
You are right that the C standard only talks about diagnostics, but this doesn't change the fact that implicit casts between unrelated pointer types are not treated as hard errors.
- 1718627440 5mo ago
  That's what I addressed in the first paragraph, a warning in C is a serious thing, not just some random nuisance.
  - spacechild1 5mo ago
    Ok, but then compilers should really throw errors for these diagnostics by default. Why lump serious issues like incompatible pointer casts together with benign things like uninitialized variables? (Another pet peeve of mine is that missing returns in functions is not considered a hard error. GCC 16 does not even issue a warning by default when compiling C code, which is just crazy. "-Werror=return-type" is the first thing I do in every new C or C++ project. I don't understand how this is still not the default...)
    - 1718627440 5mo ago
      > Ok, but then compilers should really throw errors for these diagnostics by default. That's because the default mode for compilers is to just shut up and compile this throw away code. Programmers know that you are expected to turn the warnings on and also nobody is manually invoking compilers directly. The default for build systems is often "-Wall -O2" anyway. Personally I prefer the status quo, I hate tools, that I just invoke and they start spamming my terminal. "Like, I know, that there will be issues, that's why I'm using you, but you don't need to tell me until I told you what exactly you are supposed to report me. Don't spam me until I ask you." > Why lump serious issues like incompatible pointer casts together with benign things like uninitialized variables? ?? Uninitialized variables are also serious issues and also undefined behaviour. If anything they're more serious, because for pointer casts, it is likely that the types are compatible, but the compiler just doesn't know it, while truly uninitialized variables are always a real error. For the latter, the issue is rather, that the compiler often can't proof whether the variables are actually uninitialized. That's why it is more likely to meet a "maybe-uninitialized", a true "uninitialized" is rare in the wild.
      - spacechild1 5mo ago
        > That's because the default mode for compilers is to just shut up and compile this throw away code. That's just not true. Compilers do issue certain warnings by default and they even treat some warnings as errors. See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > ?? Uninitialized variables are also serious issues and also undefined behaviour. Oh my, I meant to write "unused variables" facepalm. Uninitialized variables are of course a serious issue. So back to my original point: you said that warnings in C are always a serious thing, but that's not really true. Warnings can range from more or less harmless to very serious. In fact, compilers recognize this issue by upgrading certain warnings to errors by default. See again my link to the GCC 14 post: https://gcc.gnu.org/gcc-14/porting_to.html https://gcc.gnu.org/gcc-14/porting_to.html.
        1718627440 5mo ago
        > That's just not true. Compilers do issue certain warnings by default and they even treat some warnings as errors. Because some warnings are just believed to be more serious, than others. > In fact, compilers recognize this issue by upgrading certain warnings to errors by default. Which I interpret as a culture shift, due to people complaining about it and also because the contemporary meaning and expectation of warnings for programming languages has shifted.