Fix gcc4 mangling complex constchar

[twitwi]

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?

[ochafik]

Wow, thanks Rémi and sorry for the atrocious delay!