> 1. Explicitly set the C standard to C17 or older, so the code is built using the custom boolean type.

> Option 1) seemed like the easiest one, but it also felt a bit like kicking the can down the road – plus, it introduced the question of which standard to use.

Arguably, that's the sanest one: you can't expect the old C code to follow the rules of the new versions of the language. In a better world, each source file would start with something like

    #pragma lang_ver stdc89

and it would automatically kick off the compatibility mode in the newer compilers, but oh well. Even modern languages such as Go miss this obvious solution.

On the topic of the article, yeah, sticking anything other than 0 or 1 into C99 bool type is UB. Use ints.

▲ wk_end 3 hours ago | parent | next [-]

Yeah, it’s only kicking the can down the road if you’re the actual maintainer of the software.

If you’re just a packager, it’s your job to get the package to build and work correctly; for your own sanity, you should be making minimal changes to the underlying code to facilitate that. Get it building with the old language version and file a bug report.

▲ netburst 35 minutes ago | parent | prev | next [-]

Since you mention Go, it does offer precisely the feature you describe in the form of build constraints. A file starting with

  //go:build go1.18

tells the toolchain to use Go 1.18. A slightly different syntax was used prior to Go 1.17 but the feature itself has existed since Go 1.0.

▲ Tuna-Fish 5 hours ago | parent | prev | next [-]

Rust does the right thing, with the per-crate

    edition =

statement.

▲ nomel 3 hours ago | parent | prev [-]

> you can't expect the old C code to follow the rules of the new versions of the language

Well, to be pedantic, the entire point of the C standard, and the standard body, is that you should expect it to work, as long as you're working within the standard!

▲

Joker_vD 2 hours ago | parent [-]

Not really, no. Newer versions of standard can (and do, although rarely, I have give it to C standard committee) introduce incompatibilities with earlier versions of standard. E.g. at one point the standard explicitly allowed to #undef "bool", "true", and "false" (and to redefine them later) but IIRC this has been deprecated and removed.

In any case: blindly switching what is essentially a typedef-ed int into _Bool has no business working as expected, since _Bool is a rather quirky type.

	▲	nomel 2 hours ago \| parent [-]
		I'm using the dictionary definition of expect here, which is compatible with what you're saying.