id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
4423,fix for #4400,Wolf Lammen <ookami1@…>,No-Maintainer,"The attached patch file fixes the bug described in ticket #4400

Yet to be done: has somebody access to a compiler based on Edison Design Group C++ front end version 3.0.8 or earlier? I would like the code being compiled by such a compiler and see, whether the code fork for that compiler type runs properly.

The preprocessor code has not been touched in the past 7 years, and seemingly there is no active maintainer around, so I chose to keep the fixes impact on existing software is minimal as possible. I can tell from the sources that the author of the preprocessor code meant BOOST_PP_SEQ_REST_N to fulfil a certain undocumented condition, which it violates in a single case, so a good fix would care about said condition. But BOOST_PP_SEQ_REST_N is much more at the core of the preprocessor, and a change affects more code. So, instead, I made the only client BOOST_PP_SEQ_REPLACE  relying on that condition when BOOST_PP_SEQ_REST_N fails to fulfil it, independent of BOOST_PP_SEQ_REST_N.

The code contains a compiler fork, that treats preprocessors with rescanning and/or argument substitution problems differently. I used the same technics I found elsewhere in boost code to work around that problems. I think I it is ok, and my (compliant) compiler does not complain, but, of course, there is a slight chance I got it wrong.

To verify the fix is correct I used a self written test suite, that checks the validity of a BOOST_PP_SEQ_REPLACE
implementation. It uses a brute force method, i.e. sequences of all possible lengths are tested, each element is replaced, and each replacement is individually checked. The test suite allows for varying the input sequence, so sequences containing characters with special meaning to the preprocessor has been tested as well.
The test suite is a UNIX bash shell script, which I attached here as well.

The test results show without exception so far,
- that the fixed code produces exactly the same results than the old code, whereever the old code succeeds. This includes the distribution of white space characters in between sequence elements;
- that the fixed code produces the correct result, where the old code fails;
- that the same holds if the BOOST_PP_CONFIG_EDG flag is forced. However, the GNU preprocessor I used is standard compliant, so an old EDG based compiler might still fail.

As I changed the code in seq_replace.hpp significantly, and in a not trivial manner, I added my copyright notice.

Cheers

Wolf Lammen",Patches,closed,Boost 1.44.0,preprocessor,Boost 1.44.0,Problem,duplicate,,