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: <https://svn.boost.org/trac/boost/ticket/4421#comment:7> Boost C++ Libraries <http://www.boost.org/> 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