ROOT: pedantic error in dictionary

I sent the following message on April 6th and May 18th, but others say they never saw it out from the list, so I'll resend it (this time sans attachment) and again ask for help from the ROOT team. The example can be found at:
  http://home.fnal.gov/~rhatcher/pedantic.tar.gz

In MINOS we compile all our code with the -pedantic-errors flag. For the last year or so, when compiling with gcc 4.x (Linux or Mac OS X), we've been getting an annoying warning message when compiling the dictionary.

$ ./buildMyClass.sh
i686-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

compile dictionary with extra " "
compile dictionary with extra "-pedantic-errors"

MyPkgCint.cc: In function 'void G__setup_memfuncBeamType()':
MyPkgCint.cc:243: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object
MyPkgCint.cc:244: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object
MyPkgCint.cc:245: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object
MyPkgCint.cc:246: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object
MyPkgCint.cc:247: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object
MyPkgCint.cc:248: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object

One example of such a line is:

G__memfunc_setup("AsString",811,G__MyPkgCint_82_0_1, 67, -1,  G__defined_typename("Char_t"), 0, 1, 1, 1, 1, "u 'BeamType::EBeamType'  'BeamType::BeamType_t' 0 - b", (char*)NULL,
(void*) (const Char_t* (*)(BeamType::BeamType_t))(&BeamType::AsString), 0);

The offending part is the second to last argument, the
(const Char_t* (*)(BeamType::BeamType_t))(&BeamType::AsString)
being cast to a void*.

Is there any way that the dictionary interface could avoid this? Or are we stuck ignoring these ... and there are many of them per dictionary ... forever? As more of our users migrate to gcc 4.x it's becoming more problematic as it obscures other errors and warnings.

-robert

Robert W. Hatcher | rhatcher_at_fnal.gov 630-840-3102 FNAL CD/EXP (MINOS) | MS 220, PO Box 500, Batavia IL 60510 Received on Mon May 21 2007 - 23:13:27 CEST