|
Boost : |
From: Michiel Salters (michiel.salters_at_[hidden])
Date: 2005-02-09 10:50:52
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Hartmut Kaiser
> Sent: woensdag 9 februari 2005 14:42
> To: boost_at_[hidden]
> Subject: RE: [boost] Wave C++ Review Begins Today - February 7, 2005
>
>
> Michiel Salters wrote:
> > one serious bug in wave\cpplexer\re2clex\cpp_re2c_lexer.hpp:
> > template <typename IteratorT, typename PositionT> inline
> > lexer<IteratorT, PositionT>::lexer(IteratorT const &first,
> > IteratorT const &last, PositionT const &pos,
> > boost::wave::language_support language)
> > : filename(pos.get_file()), at_eof(false)
> > {
> > memset(&scanner, '\0', sizeof(Scanner));
> > scanner.fd = -1;
> > scanner.eol_offsets = aq_create();
> > scanner.first = scanner.act = (uchar *)&(*first);
> > scanner.last = (uchar *)&(*last);
> > ...
> > [ IteratorT = std::string::iterator in the example ]
> >
> > This assumes that the range [first,last] is dereferenacable and
> > contiguous in memory. This of course is not mandated by the
> standard.
>
> Yes, this is a known problem (see the Changelog file), I
> didn't realise, that it will assert on some systems. Seems,
> that I'll have to fix that soon ;-). This shouldn't be a
> problem on other systems, though, if you're using iterators
> acting on a continuous chunk of memory (such as
> std::string::iterator).
No, you're mistaken here and in the Changelog as well. Even
std::string::iterator doesn't have to refer to contiguous
memory. std::vector<char>::iterator would, though, so I built
a string around that and found the actual bug (and a VC8 bug
as well I think).
The bug is that context<IteratorT> stores the two iterators
first and last as const&. The cpp example passed .begin() and
.end(), which are temporaries and they go out of scope.
The result is that the context ends up with references to
destructed iterators. Again, the VC8 STL iterator debugging
found the problem on first access.
Line 281, cpp_context.hpp
I really have to say Dinkumware did a fine job here, this
would have been very hard to find without these checks.
> OTOH this isn't exactly a problem in the preprocessor
> library, it's merely a problem of the re2c generated lexer
> used in the driver. The other provided lexer (SLEX based)
> won't expose this problem (i.e. the cpp_tokens example
> shouldn't assert).
Might be (didn't get there yet), but it too uses
cpp_context.hpp, right?
BTW, if you try VC8, mail me for the string class I used.
Using std::vector<char> directly appears to trigger a
VC 8(beta1) bug with typenames longer than 2KB
Regards,
Michiel Salters
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk