Re: [RFA] Fix a memory corruption in mdebugread.c

[Joel Brobecker <brobecker@gnat.com>]

Hi Daniel,

> So I assume the stProc is nested directly in the type, and we generate
> a complaint() in the default below?

Right.

> It's worth bearing in mind that we don't actually support C++ in
> mdebugread; debugging the C++ part won't work well at all.  We won't
> recognize any member methods for instance.

This is indeed good to know, although I kind of guessed this after
reading the code in mdebugread.c :).

> My concern from your description is that a constructor may have the
> same name as the enclosing type.  Are these mangled names?  Qualified
> names?  Base names, in which case the constructor is a problem?  You
> should be able to figure this out from looking at a couple of the names
> found by the check below.

The method names are mangled, same for the constructors and destructors.
For instance, one of the constructors for class TC_rule was
__ct__7TC_ruleXRC7TC_rule. The destructor was __dt__7TC_ruleXv
(actually, I assumed these stProc entries are constructors and
destructors, but this a guess based on the name). An example of stProc
entry for a method: FI_write__7TC_ruleXP4FILE.

stMembers, on the other hand, are not mangled. But they don't come with
stEnd entries, so we should be safe.

> That's not a proper ChangeLog entry; it should be smeting like:
> 
> 2002-12-31  J. Brobecker  <brobecker@gnat.com>
> 
> 	* mdebugread.c (parse_symbol): Count until the stEnd matching
> 	the structure name.

Sure!

-- 
Joel