Fix gcc4 mangling complex constchar

Following mails reporting issues on the mailing list (replicated below), I fixed the "const char*" problems that appear as soon as the case is not trivial. I added the provided example as a test.

@ochafik : it has been tested only with "mvn -Dtest=org.bridj.DemanglingTest test", so it might be worth testing on a wider scope before merging.

On Monday, July 27, 2015 at 12:17:50 PM UTC-7, Kurt Granroth wrote:

   I'm using com.nativelibs4java.bridj.0.7.0 on a CentOS 5 system
   running Java 1.8.  gcc version 4.1.2; x64

   Let's say I have a C++ method like so:

   bool create( const char *template, const char *name);

   When linked into a shared library, it gets mangled into this:

   _ZN16cmd_create_event6createEPKcS1_

   This mangled name appears correct in that I can link to it from
   another C++ app with on problem.  Also, running 'nm --demangle' on
   the shared lib correctly demangles that name to the proper one.

   When I try to use this shared library with bridj, though, I get this
   error:

   org.bridj.demangling.Demangler$DemanglingException: Encountered a
   unexpected gcc mangler shortcut '1_' [a, b, s, t, d, i, o, _, 0_]
   (in symbol '_ZN16cmd_create_event6createEPKcS1_')

   That's not the only function that behaves like this -- I see
   hundreds of these errors for that library.

   I was able to work around that particular case by replacing the two
   string parameters with one struct, which had the two strings as
   member variables.  That works, if non-ideally.

   But I can't replace all 'const char*' instances with structs.
     Here's another example:

   const char *error() const;

   That's mangled into:

   _ZNK16cmd_create_event5errorEv

   The bridj parser doesn't like that one, either:

   org.bridj.demangling.Demangler$DemanglingException: Parsing error at
   position 3: Expected a number

            _ZNK16cmd_create_event5errorEv

               ^ (in symbol '_ZNK16cmd_create_event5errorEv')

   I'm not sure what to do in these cases.  Using the 'Symbol'
   annotation workaround doesn't help, since it's not so much a mapping
   problem as the fact that the bridj demangler doesn't think my
   methods are valid.

   Thoughts?

nativelibs4java / BridJ

Fix gcc4 mangling complex constchar #77