Fix boolean typedef for C23

[suve]

The C23 standard elevates "false" and "true" to keywords, making it illegal to use them as enum variant names. This commit makes the code use the built-in "bool" type when building with C23 or later.

[turol]

Do we want this or do we want to set the C standard to 89?

[suve]

That's another possibility - neither CMake nor autotools seem to set the C standard anywhere, so the engine gets built with whatever is the compiler's default.

I came across this while rebuilding the chocolate-doom package for the upcoming Fedora Linux 42, which uses the GCC 15 pre-release. Among other changes, GCC 15 changes the default C standard from gnu17 to gnu23¹.

Footnotes

1. https://gcc.gnu.org/gcc-15/porting_to.html#c23 ↩

[chungy]

I believe current GCC and Clang releases default to the C11 standard (with extensions), that's probably the safe baseline for Chocolate Doom.

C23 reserving true and false seems like a fairly large gotcha, but I have no problem with futureproofing the code.

[suve]

I believe current GCC and Clang releases default to the C11 standard (with extensions)

Nope. The last version of GCC that defaulted to -std=gnu11 was GCC 10¹. Starting with GCC 11, the default is std=gnu17².

Footnotes

1. https://gcc.gnu.org/onlinedocs/gcc-10.5.0/gcc/Standards.html#C-Language ↩

2. https://gcc.gnu.org/onlinedocs/gcc-11.5.0/gcc/Standards.html#C-Language ↩

[suve]

Just checked clang, and it's similar there - it defaulted to gnu11 until clang 10¹; this was changed to gnu17 in clang 11².

For reference, GCC 11.1 was released in April 2021³ and clang 11 in October 2020⁴.

Footnotes

1. https://releases.llvm.org/10.0.0/tools/clang/docs/UsersManual.html#c-language-features ↩

2. https://releases.llvm.org/11.0.0/tools/clang/docs/UsersManual.html#c-language-features ↩

3. https://gcc.gnu.org/releases.html ↩

4. https://releases.llvm.org/ ↩

[rfomin]

Do we want this or do we want to set the C standard to 89?

C89 won't work because <stdint.h> and // style comments are used everywhere. I think C99 is the most reasonable conservative choice.

[fabiangreffrath]

For reference, GCC 11.1 was released in April 2021

GCC 15 will be released this year and will default to C23, which will require a whole new order of magnitude of code changes to properly support it.

C89 won't work because <stdint.h> and // style comments are used everywhere. I think C99 is the most reasonable conservative choice.

Yes, right. We already use C99 features in the code, so the right thing to do will be to declare our code as C99 compliant and require a compatible compiler. While at it, when declaring as C99 compliant, we may unconditionally include the <stdbool.h> header and just use this.

I'm going to prepare a PR now.

[fabiangreffrath]

GCC 15 will be released this year and will default to C23, which will require a whole new order of magnitude of code changes to properly support it.

At least this is what I had to do to properly compile Woof with gcc-15. No idea why Chocolate gets away with only this one change here.

https://github.com/fabiangreffrath/woof/pull/2094/files

[turol]

I suspect it's because chocolate uses void where woof uses an actual type. Void pointer has always been slightly magical with casting.