`CHAOS_PP_ASSERT_MSG` doesn't fail when cond is false

[brvtalcake]

Hi,

Even though this project is not alive anymore, I still use it in my own ones, either to learn/draw inspiration from it or just to use it normally. I don't know if pull requests are accepted, so please tell me and I will fix the code. Else I will just fork it for my own use and modify it.

Kind regards.

Axel

[rofl0r]

sure, if there's an obvious bugfix i can merge it, so please go ahead

[brvtalcake]

Thanks (and sorry for the late reply). Will do so as soon as I have some time (this week)

[brvtalcake]

Hello. First of all, sorry for forgetting. If I remember correctly, I had a problem with my PC which led me to not being able to program at home for a whole month or so. And then well, I just got distracted by my own occupations

I also remember myself comparing boost-pp to chaos-pp as both libs have this construct, but it turns out they both do the same thing.

I'm a little bit sad from the fact that I didn't take the time to post the code I thought was problematic, because I can't exactly remember what made me think there was a problem in the first place.

But I think the problem was that while CHAOS_PP_ASSERT(cond) expands to CHAOS_PP_FAILURE() when cond is 0 (hence aborting any further preprocessing as expected, due to the way CHAOS_PP_FAILURE() is defined), CHAOS_PP_ASSERT_MSG(cond, msg) on the other hand does not fail directly, but instead expands to a string (which then could cause a compile error if the string ends up in some invalid context, but could as well be totally fine in some other cases, i.e. in expression position or statement position, if followed by a semicolon).

Three possible ideas, though not perfect since I believe it's not possible to truly abort preprocessing with a clear message without using e.g. compiler-specific pragmas or stuff like that (even a pragma would not necessarily cause a preprocessing error per se anyways) :

1. Make CHAOS_PP_FAILURE accept one argument (a variadic one when CHAOS_PP_VARIADICS != 0), that would expand to CHAOS_IP_FAILURE_I( <msg|__VA_ARGS__> !) instead of CHAOS_IP_FAILURE_I(!), and make CHAOS_PP_ASSERT_MSG use that with the message param : this wouldn't break any existing code since 0 args == 1 empty arg in CPP parlance
2. Create a CHAOS_PP_FAILURE_MSG, that would do just about the same, but as a different macro, and make CHAOS_PP_ASSERT_MSG use that with the message param : same as above
3. Just skip using the message param and expand to a regular CHAOS_PP_FAILURE(), which would still make the message available in the macro expansion "bracktrace" and provided an actual preprocessing error

[rofl0r]

I believe it's not possible to truly abort preprocessing with a clear message without using e.g. compiler-specific pragmas or stuff like that (even a pragma would not necessarily cause a preprocessing error per se anyways)

there's #error and i do think it's standardized, though i'm not entirely certain about it.

[brvtalcake]

there's #error and i do think it's standardized, though i'm not entirely certain about it.

Hmmm, yes, surely you can use a #error at global file scope, but not from macro definition. You can't make a C preprocessor macro expand to #error. You could do this if there was some kind of _Error, akin to _Pragma.

[aoi-buh]

you can do something like

#define error(m) m##.

it would stop precompilation and display the full error message but it's ugly