Re: [Boost-bugs] [Boost C++ Libraries] #4421: fix for #4400

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4421: fix for #4400
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-08-31 12:56:51

#4421: fix for #4400
  Reporter: Wolf Lammen <ookami1@…> | Owner: no-maintainer
      Type: Patches | Status: new
 Milestone: Boost 1.44.0 | Component: preprocessor
   Version: Boost 1.44.0 | Severity: Problem
Resolution: | Keywords:

Comment (by ookami1@…):

 The only indirect callers of BOOST_PP_SEQ_SPLIT within boost, but outside
 of preprocessor/seq, I could find, are macros in:

 mpl/aux_/preprocessor/range.hpp (and their users)

 parameter/preprocessor.hpp (and their users)

 Only for some calls to BOOST_PP_SEQ_FIND_N in parameter/preprocessor.hpp I
 was unable to rule out they pass empty sequences, mostly, because I got
 lost in the hierarchies of layers found there.
 If (that is not for sure!) they really pass empty sequences to the
 preprocessor, then
 1. this violates the documented limitations of the preprocessor code;
 2. this is likely to fail on exotic compilers, because some do not support
 empty macro parameters at all.

 So, what line is to follow here? Fortify BOOST_PP_SEQ_FIRST_N such that it
 tolerates abuses to the extent possible? Stay within the asserted
 limitations and let bugs surface in dependent code? Notify the maintainers
 of boost/parameter of possible conflicts? Start a discussion on the
 mailing list? Give up on supporting sequences of size 256 altogether and
 decrement BOOST_PP_LIMIT_SEQ (currently set to 256, but I know many macros
 (if not the majority) in preprocessor/seq do not support this limit)?

Ticket URL: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:04 UTC