4 ms·

All the weird stuff I have read about C or C++ doing over the years could be summed up with “Well… don’t do that.” Like almost without fail. I can’t even think

All the weird stuff I have read about C or C++ doing over the years could be summed up with “Well… don’t do that.” Like almost without fail. I can’t even think of how you’d end up in a scenario like this because a compiler would complain before letting you use an undefined implicit declaration.

bitbasher 2mo ago
That doesn't make it any less interesting :)
- stinkbeetle 2mo ago
  It does. Some people would still be interested but lots of people would not. The net interestingness would certainly decrease.
Joel_Mckay 2mo ago
Most people build C in g++ before gcc, as it tends to have a better chance of catching most oddities. Then run it past valgrind to double check if something looks suspect or is slowly leaking. =3
- koe123 2mo ago
  Ray William Johnson…?
  - Joel_Mckay 2mo ago
    Google Gemini? =3 https://www.youtube.com/watch?v=X6WHBO_Qc-Q https://www.youtube.com/watch?v=X6WHBO_Qc-Q
- flohofwoe 2mo ago
  > Most people build C in g++ before gcc That's not possible for 'standard C' though, only for the separate language that's called "the common subset of C and C++". E.g. it works more or less by accident for some specific C code that predates C99, but even that is built with C++ semantics (which has many subtle and some not-so-subtle differences to C semantics). Instead of trying to build C in C++ mode, turn all the warnings to 11 (and also include warnings that aren't in -Wall -Wextra, like -Wsign-conversion).
  - Joel_Mckay 2mo ago
    The 'g++ -x c ...' will parse portable source just fine (compiles code as C, but links against libstdc++), and tends to identify poorly structured code with verbose checks. If people default to gcc file extension inference, than it is likely to remain silent when people do something silly. Best of luck, =3 https://www.man7.org/linux/man-pages/man1/g++.1.html https://www.man7.org/linux/man-pages/man1/g++.1.html
    - flohofwoe 2mo ago
      Tbh I would be very surprised if `g++ -x c` and `gcc` use different language frontends. One silly side effect of compiling C in C++ mode is that it forces you to cast from void pointers. E.g. the famous example of: bla_t* bla = (bla_t*)malloc(sizeof(bla_t)); That extra cast is just a silly and completely pointless C++-ism. It's only the tip of the iceberg though (another difference was zero-initialization with `{}` vs `{0}`, but that's harmonized now in C23 so that `{}` is also valid in C, but as soon as you want to use C99 designated init, the 'harmonization' ends). One critical missing piece of C compilation mode was usually that the compiler didn't warn when using a wrong enum type, but that's also fixed by now (assuming `-Wall -Wextra`, but that should always be enabled anyway, otherwise you're just flying blind), e.g.: https://www.godbolt.org/z/h5s4qWoTh https://www.godbolt.org/z/h5s4qWoTh
      - uecker 2mo ago
        Yes, g++ -xc will call the regular C FE. So yes, do not try to compile C code using a C++ compiler. That you somehow get superior type checking with C++ is not really true anymore, as essentially all important parts were integrated into the C standard and the remaining should all exist as optional warnings in gcc. If you feel something is missing, please file a bug.
        Joel_Mckay 2mo ago
        The key logical jump here is "should", but in practice standards compliant C may still behave in unintuitive ways in edge-cases. It is not a compiler "bug" if functioning as defined, but rather a self-discipline issue to avoid shitty coding practices. =3
mjevans 2mo ago
I sum it up with: give me an error message rather than undefined or unintuitive behavior.
maccard 2mo ago
What language doesn’t have its own set of absolutely monstrous footguns? https://github.com/denysdovhan/wtfjs https://github.com/denysdovhan/wtfjs - https://github.com/satwikkansal/wtfpython https://github.com/satwikkansal/wtfpython - https://news.ycombinator.com/item?id=31216080 https://news.ycombinator.com/item?id=31216080 - https://www.dolthub.com/blog/2023-08-16-go-pitfalls/ https://www.dolthub.com/blog/2023-08-16-go-pitfalls/ are all examples of pitfalls of a few languages. I’m not going to defend all of the ones C(++) has but stuff like deref’ing null or integer overflow or out of bounds access has its roots in sanity, it just looks insane today. There are tools for many/most of these and if you’re not using them you’re doing it wrong.

bitbasher 2mo ago

That doesn't make it any less interesting :)

stinkbeetle 2mo ago
It does. Some people would still be interested but lots of people would not. The net interestingness would certainly decrease.

Joel_Mckay 2mo ago

Most people build C in g++ before gcc, as it tends to have a better chance of catching most oddities. Then run it past valgrind to double check if something looks suspect or is slowly leaking. =3

koe123 2mo ago
Ray William Johnson…?
- Joel_Mckay 2mo ago
  Google Gemini? =3 https://www.youtube.com/watch?v=X6WHBO_Qc-Q https://www.youtube.com/watch?v=X6WHBO_Qc-Q
flohofwoe 2mo ago
> Most people build C in g++ before gcc That's not possible for 'standard C' though, only for the separate language that's called "the common subset of C and C++". E.g. it works more or less by accident for some specific C code that predates C99, but even that is built with C++ semantics (which has many subtle and some not-so-subtle differences to C semantics). Instead of trying to build C in C++ mode, turn all the warnings to 11 (and also include warnings that aren't in -Wall -Wextra, like -Wsign-conversion).
- Joel_Mckay 2mo ago
  The 'g++ -x c ...' will parse portable source just fine (compiles code as C, but links against libstdc++), and tends to identify poorly structured code with verbose checks. If people default to gcc file extension inference, than it is likely to remain silent when people do something silly. Best of luck, =3 https://www.man7.org/linux/man-pages/man1/g++.1.html https://www.man7.org/linux/man-pages/man1/g++.1.html
  - flohofwoe 2mo ago
    Tbh I would be very surprised if `g++ -x c` and `gcc` use different language frontends. One silly side effect of compiling C in C++ mode is that it forces you to cast from void pointers. E.g. the famous example of: bla_t* bla = (bla_t*)malloc(sizeof(bla_t)); That extra cast is just a silly and completely pointless C++-ism. It's only the tip of the iceberg though (another difference was zero-initialization with `{}` vs `{0}`, but that's harmonized now in C23 so that `{}` is also valid in C, but as soon as you want to use C99 designated init, the 'harmonization' ends). One critical missing piece of C compilation mode was usually that the compiler didn't warn when using a wrong enum type, but that's also fixed by now (assuming `-Wall -Wextra`, but that should always be enabled anyway, otherwise you're just flying blind), e.g.: https://www.godbolt.org/z/h5s4qWoTh https://www.godbolt.org/z/h5s4qWoTh
    - uecker 2mo ago
      Yes, g++ -xc will call the regular C FE. So yes, do not try to compile C code using a C++ compiler. That you somehow get superior type checking with C++ is not really true anymore, as essentially all important parts were integrated into the C standard and the remaining should all exist as optional warnings in gcc. If you feel something is missing, please file a bug.
      - Joel_Mckay 2mo ago
        The key logical jump here is "should", but in practice standards compliant C may still behave in unintuitive ways in edge-cases. It is not a compiler "bug" if functioning as defined, but rather a self-discipline issue to avoid shitty coding practices. =3

mjevans 2mo ago

I sum it up with: give me an error message rather than undefined or unintuitive behavior.

maccard 2mo ago

What language doesn’t have its own set of absolutely monstrous footguns? https://github.com/denysdovhan/wtfjs https://github.com/denysdovhan/wtfjs - https://github.com/satwikkansal/wtfpython https://github.com/satwikkansal/wtfpython - https://news.ycombinator.com/item?id=31216080 https://news.ycombinator.com/item?id=31216080 - https://www.dolthub.com/blog/2023-08-16-go-pitfalls/ https://www.dolthub.com/blog/2023-08-16-go-pitfalls/ are all examples of pitfalls of a few languages. I’m not going to defend all of the ones C(++) has but stuff like deref’ing null or integer overflow or out of bounds access has its roots in sanity, it just looks insane today. There are tools for many/most of these and if you’re not using them you’re doing it wrong.