id summary reporter owner description type status milestone component version severity resolution keywords cc 4400 BOOST_PP_SEQ_REPLACE fails in corner cases Wolf Lammen No-Maintainer "The following code replaces individual elements (first the 255th, then the 256th) in a given preprocessor sequence of length 256. I noticed that sometimes the element is not replaced, but inserted instead, yielding a longer sequence. Using Boost version 1.4.3, the following code will not compile -------------------------------------------------- {{{ /* * booster.cpp * * Created on: 25.06.2010 * Author: Wolf Lammen */ #include ""boost/preprocessor.hpp"" #define SEQ_256 \ (1)(2)(3)(4)(5)(6)(7)(8)(9) \ (10)(11)(12)(13)(14)(15)(16)(17)(18)(19) \ (20)(21)(22)(23)(24)(25)(26)(27)(28)(29) \ (30)(31)(32)(33)(34)(35)(36)(37)(38)(39) \ (40)(41)(42)(43)(44)(45)(46)(47)(48)(49) \ (50)(51)(52)(53)(54)(55)(56)(57)(58)(59) \ (60)(61)(62)(63)(64)(65)(66)(67)(68)(69) \ (70)(71)(72)(73)(74)(75)(76)(77)(78)(79) \ (80)(81)(82)(83)(84)(85)(86)(87)(88)(89) \ (90)(91)(92)(93)(94)(95)(96)(97)(98)(99) \ (100)(101)(102)(103)(104)(105)(106)(107)(108)(109) \ (110)(111)(112)(113)(114)(115)(116)(117)(118)(119) \ (120)(121)(122)(123)(124)(125)(126)(127)(128)(129) \ (130)(131)(132)(133)(134)(135)(136)(137)(138)(139) \ (140)(141)(142)(143)(144)(145)(146)(147)(148)(149) \ (150)(151)(152)(153)(154)(155)(156)(157)(158)(159) \ (160)(161)(162)(163)(164)(165)(166)(167)(168)(169) \ (170)(171)(172)(173)(174)(175)(176)(177)(178)(179) \ (180)(181)(182)(183)(184)(185)(186)(187)(188)(189) \ (190)(191)(192)(193)(194)(195)(196)(197)(198)(199) \ (200)(201)(202)(203)(204)(205)(206)(207)(208)(209) \ (210)(211)(212)(213)(214)(215)(216)(217)(218)(219) \ (220)(221)(222)(223)(224)(225)(226)(227)(228)(229) \ (230)(231)(232)(233)(234)(235)(236)(237)(238)(239) \ (240)(241)(242)(243)(244)(245)(246)(247)(248)(249) \ (250)(251)(252)(253)(254)(255)(256) #if BOOST_PP_SEQ_SIZE(BOOST_PP_SEQ_REPLACE(SEQ_256, 254, a)) != 256 # error ""replacement at 254: size of sequence has changed"" #endif #if BOOST_PP_SEQ_SIZE(BOOST_PP_SEQ_REPLACE(SEQ_256, 255, a)) != 256 # error ""replacement at 255: size of sequence has changed"" #endif int main() { return 0; } }}} -------------------------------------------------- Here is the error message: Invoking: GCC C++ Compiler g++ -I""/home/wolf/workspace/booster"" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF""booster.d"" -MT""booster.d"" -o""booster.o"" ""../booster.cpp"" ../booster.cpp:42:3: error: #error ""replacement at 255: size of sequence has changed"" Note that the first call to BOOST_PP_SEQ_REPLACE succeeded. I use the GNU Compiler collection version (Ubuntu 4.4.1-4ubuntu9) 4.4.1 on x86_64 GNU/Linux =================== ANALYSIS OF THE BUG ====================== According to the documentation, valid ranges of lengths of boost preprocessor sequences are from 1 to BOOST_PP_LIMIT_SEQ (=256). Especially empty sequences are not allowed. This overall restriction imposes limits to parameters of macros related to sequences. In particular, you must not call {{{ BOOST_PP_SEQ_REST_N(i, seq) }}} with i == BOOST_PP_SEQ_SIZE(seq), as this would force BOOST_PP_REST_N to return an empty sequence. BOOST_PP_SEQ_REPLACE does use BOOST_PP_REST_N in this way, thus relying on undefined behavior. Here is how BOOST_PP_SEQ_REPLACE is defined: {{{ # define BOOST_PP_SEQ_REPLACE(seq, i, elem) BOOST_PP_SEQ_FIRST_N(i, seq) (elem) BOOST_PP_SEQ_REST_N(BOOST_PP_INC(i), seq) }}} If i points to the last element of the sequence, it equals (size(seq) - 1) and BOOST_PP_INC(i) yields size(seq), an invalid argument to BOOST_PP_REST_N. I called BOOST_PP_REST_N with an offset equal to size(seq) for various sequences, and even though this was outside of the specifications, it expanded to an empty string - most of the time. An empty string would have been fine for BOOST_PP_SEQ_REPLACE, but unfortunately, BOOST_PP_REST_N failed to do so for sequences of maximum size. It internally increments its first parameter, and since incrementation saturates at 256, the algorithm delivers a different result then. ========================= FIX ====================== Here is a suggestion on how to fix this: Extend the domain of BOOST_PP_REST_N and allow the first parameter to be equal to the size of the sequence. Make the macro reliably expand to an empty string then: {{{ #define BOOST_PP_SEQ_REST_N(n, seq) BOOST_PP_IF(n, BOOST_PP_TUPLE_ELEM(2, 1, BOOST_PP_SEQ_SPLIT(BOOST_PP_INC(BOOST_PP_DEC(n)), seq BOOST_PP_EMPTY))(), seq) }}} This is quick and dirty, and not optimal, because BOOST_PP_TUPLE_ELEM is always evaluated, but according to my tests it works. As I am not an experienced macro programmer, I would like to leave the details to your experts. With kind regards Wolf Lammen " Bugs closed Boost 1.44.0 preprocessor Boost 1.44.0 Problem fixed