Yeah, it’s only kicking the can down the road if you’re the actual maintainer of the software.
replyIf 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.
Since you mention Go, it does offer precisely the feature you describe in the form of build constraints. A file starting with
reply //go:build go1.18
Rust does the right thing, with the per-crate
reply edition =
> you can't expect the old C code to follow the rules of the new versions of the language
replyWell, 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!
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.
replyIn 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.
I'm using the dictionary definition of expect here, which is compatible with what you're saying.
reply