I would like to second this. ☺

It may also be useful (IMO) if this __CPROC__ macro could expand to some sort of compiler version indicator (much like __GNUC__).

Thank you!

My main worry with this is that people will use it to disable use of some feature (like a builtin) that cproc didn't have at the moment, but if it ever gains that feature, then the code won't reflect that.

It's best to test for availability of features you want to use instead of hard-coding assumptions about features provided by particular implementations.

It's best to test for availability of features you want to use instead of hard-coding assumptions about features provided by particular implementations.

There are many features whose presence (let alone proper working implementation) can't be tested: VLA, __has_builtin, inline assembly, _Complex…

There are many features whose presence (let alone proper working implementation) can't be tested: VLA, __has_builtin, inline assembly, _Complex…

I'm not sure what you mean. All of these can easily be tested for. VLAs and _Complex don't even need tests; you can just use standard predefined macros:

__STDC_NO_VLA__ The integer constant 1, intended to indicate that the implementation does not support variable length arrays or variably modified types.

__STDC_NO_COMPLEX__ The integer constant 1, intended to indicate that the implementation does not support complex types or the <complex.h> header.

cproc defines both of these at the moment, but won't in the future as those features get implemented.

If you don't want to test for inline assembly support, since it's a GNU C extension, I think it's best to do the portable thing by default and only use them when __GNUC__ is defined, indicating a compiler supporting GNU C. Even better, guard by defined(__GNUC__) || HAVE_GNU_INLINE_ASM so that you could easily opt-in manually or through the result of a configure test.

__has_builtin is a bit of a special case and is intended to avoid the need for testing for builtins. While we are using gcc as a preprocessor (hopefully not for long), we can't override the behavior of __has_builtin. We can undefine it for cproc by adding -U __has_builtin to config.h at the cost of annoying warnings that can't be silenced. For now, my suggestion is to still test for builtins you need, or build cproc with -U __has_builtin to prevent it from falsely claiming support for them.