The GET_VAL macro in src/builtin.cmod is invoked like this:
GET_VAL (true) GET_VAL (false) GET_VAL (null)
If you happen to include <stdbool.h>, the macro expansion might result in these functions:
get_val_1 get_val_0 get_val_null
This is because true is defined as 1 and false as 0.
This isn't a big issue for two reasons:
- src/builtin.cmod does not actually invoke <stdbool.h> - as far as I can see, nothing actually uses get_val_true and get_val_false (but I may be overlooking something)
This could be fixed by ## and # directly in the GET_VAL macro, instead of going via PIKE_CONCAT and TOSTR. Of course, that breaks on older compilers that don't support ## and #; I don't know if the Pike community still cares about them.
One could also argue that "if it ain't broke, don't fix it". That is a valid point of view. But the code is a bit fragile; sooner or later somebody might add <stdbool.h> without that it affects the GET_VAL expansion.
Do we know what compilers would break if we use ## and # more directly?
I would be surprised if any compilers break if we use ## and #. However, using TOSTR or # directly is supposed to mean different things, and most often you want to use TOSTR.
Here is a simple demonstration program:
#include <stdio.h>
#define MY_FAVORITE_COLOR black #define TOSTR(x) # x #define GREETING_1(COLOR) "Hello, lover of " # COLOR #define GREETING_2(COLOR) "Hello, lover of " TOSTR(COLOR)
int main() { puts(GREETING_1(MY_FAVORITE_COLOR)); puts(GREETING_2(MY_FAVORITE_COLOR)); }
Leaving aside the question of whether black is a color or not, this will print:
Hello, lover of MY_FAVORITE_COLOR Hello, lover of black
This is because the argument of # (and ##) is not subject to macro expansion. But, as the example above show, you normally want macro expansion to occur, so you have to add a helper macro (TOSTR and PIKE_CONCAT).
But in the case of GET_VAL, where we use true and false as arguments, we don't want to macro-expand them. At least not when <stdbool.h> is included. And we never need to expand them -- there is no need to support something convoluted like:
#define TRUTH_VALUE false GET_VAL(TRUTH_VALUE) #undef TRUTH_VALUE
#define TRUTH_VALUE true GET_VAL(TRUTH_VALUE) #undef TRUTH_VALUE
(We are trying to use jemalloc with Pike, and for some reason including the jemalloc header file also seems to include <stdbool.h>, so we ran into this issue.)
pike-devel@lists.lysator.liu.se