Re: [boost] [preprocessing] Feedback requested on a C99 preprocessor written in pure universal Python

Subject: Re: [boost] [preprocessing] Feedback requested on a C99 preprocessor written in pure universal Python
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-03-07 17:03:36

On 3/7/2017 11:16 AM, Niall Douglas via Boost wrote:
>>> pcpp by default acts as a straight preprocessor, but it can also be told
>>> to pass through #if logic it can't fully execute due to unknowns, or
>>> partially execute #if logic. It can be told to pass through #define and
>>> #undef but also execute them (or not) on a per-macro basis. It would be
>>> easy enough to tell it to not execute any preprocessing commands except
>>> #include and include guards for example.
>>
>> The practical problem with this is that source files with preprocessor
>> directives often depend on the compiler being used, with its predefined
>> macros, to generate the correct output.
>
> Do note pcpp can pass through #if logic which uses undefined macros. So
> as compiler specific macros will be undefined, all #if logic relating to
> them passes through. The output is therefore still portable across
> compilers.

Passing through all #if logic cannot be right !

#if SOME_PREDEFINED_MACRO >= some_value
some_code
#endif

#if SOME_PREDEFINED_MACRO < some_value
some_other_code
#endif

If both "some_code" and "some_other_code" are passed through I doubt the 
output will be correct.

Because of quirks in compiler preprocessors. especially VC++, a great 
deal of macro logic in Boost PP and Boost VMD is based in identifying 
compilers and their levels of C/C++ standards compliance, which is done 
by compiler predefined macros. I would imagine that this could be 
extended to others writing their own macros, whether they use Boost 
PP/VMD or not. Of course various cross-platform header files also depend 
on such information.

I am not trying to minimize your effort in any way in writing pcpp. I am 
just saying that to use it as the preprocessor front-end for various 
compilers is more complicated than I believe you think. Unless pcpp can 
create the same predefined macros which the backend compiler's 
preprocessor creates I doubt if the output can be reliable in many 
situations.

>
> Don't get me wrong, there is still a small amount of hand tuning
> involved, so a human does need to grok the output and make sure it's
> coming out okay and if not, add another command line argument to force
> things. But so far, at least for Outcome, it is coming out pretty much
> right first time (though this entirely could be how I write my
> preprocessor, and Outcome being all C++ 14 doesn't support broken
> compilers except for MSVC. So my use case is much simpler than most).