C compatibility level differs between CIL and underlying compiler, confusing configure scripts

[stephenrkell]

Recent work to add C23 support to CIL exposes a deeper issue: configure scripts will probe the underlying compiler and then end up opting us in to features that CIL doesn't support. But these codebases are portable to the earlier versions of C that we do support... it's just that we don't let their configure logic discover that they need to target an earlier version.

Possibly the right thing to do in cilpp or cilly (ideally ditching cilly as per #69) the following.

• run the underlying cpp without any input, to collect its builtins e.g. _GNU_C_PREREQ, __STDC__VERSION__ or whatever they are
• edit those to reflect our own compatibility
• run the underlying cpp disabling builtins, but prepending our tweaked builtins

[stephenrkell]

Relevant macros include:

• __STDC_VERSION__
• __GNUC__
• __GNUC_MINOR__
• __GNUC_PATCHLEVEL__
• __VERSION__ (underlying compiler version string -- can probably leave as-is)
• __GXX_ABI_VERSION (not yet something we care about)
• __STDC_IEC_60559_BFP__ (what is this? defined to 201404L on my GCC 10.x)
• __STDC_IEC_60559_COMPLEX__ (what is this? defined to 201404L on my GCC 10.x)
• __STDC_ISO_10646__2 (what is this? defined to 201706L on my GCC 10.x)

How does all this interact with -std=? Should we force -std= and drop it to the version we understand? Or should we only interfere when the client has not requested a -std= and we are getting the underlying compiler's default?

[stephenrkell]

All this is rather assuming that these macros are what configure scripts are looking at. Strictly speaking they shouldn't -- they should probe for individual feature/behaviours in a de-facto way. So it's worth picking up a real example of this first (e.g. one of the challenge codebases that were using the C23 attribute syntax perhaps).