[Gnash-dev] Truly bizarre warning in compiling LineStyle.cpp

[John Gilmore]

In libcore/LineStyle compile:

  CXX    LineStyle.lo
FillStyle.h: In member function ‘void 
gnash::LineStyle::read(gnash::SWFStream&, gnash::SWF::TagType, 
gnash::movie_definition&, const gnash::RunResources&)’:
FillStyle.h:274: warning: dereferencing pointer ‘<anonymous>’ does break 
strict-aliasing rules
/usr/include/boost/variant/detail/cast_storage.hpp:33: note: initialized from 
here
FillStyle.h: In member function ‘void 
gnash::LineStyle::read_morph(gnash::SWFStream&, gnash::SWF::TagType, 
gnash::movie_definition&, const gnash::RunResources&, gnash::LineStyle*)’:
FillStyle.h:274: warning: dereferencing pointer ‘<anonymous>’ does break 
strict-aliasing rules
/usr/include/boost/variant/detail/cast_storage.hpp:33: note: initialized from 
here
FillStyle.h:274: warning: dereferencing pointer ‘<anonymous>’ does break 
strict-aliasing rules
/usr/include/boost/variant/detail/cast_storage.hpp:33: note: initialized from 
here

So, bizarre things:

  *  The source file and line number in error is never mentioned.
  *  The warning is on FillStyle.h:274 which is the innocuous Return line in:

    /// Get the color of the fill.
    rgba color() const {
        return _color;
    }

  *  By random inspection, the problem seems to be this code:

        // TODO: store a fill style properly, removing the need for the
        // visitor.
        m_color = boost::apply_visitor(GetColor(), fp.first.fill);
        pOther->m_color = boost::apply_visitor(GetColor(), fp.second->fill);

which invokes some odd code at the top of LineStyle.cpp:

class GetColor : public boost::static_visitor<rgba>
{
public:
    rgba operator()(const SolidFill& f) const {
        return f.color();
    }
    rgba operator()(const GradientFill&) const {
        return rgba();
    }
    rgba operator()(const BitmapFill&) const {
        return rgba();
    }
};

  *  It's not actually clear what the compiler's error means.

I can't tell what this is doing, and all the Boost documentation for
it is complete gobbledygook ("Visitor Concept: Given
variant<T1,T2,...,Tn>, a function object which unambiguously accepts
any value of each of the variant's bounded types, is a Visitor of of
the variant.")  It looks to me like a perfect example of how 
object-oriented design can completely obscure the meaning of some
probably-straightforward code.

Should someone who understands this clean it up so the compiler
doesn't complain about it?

        John