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

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Jan 01, 2003 at 05:35:18PM +0400, Joel Brobecker wrote:
> 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.

OK.  Assuming that the name of the class's stEnd is not mangled like a
constructor, my worry is unfounded.  If you add a comment to that effect
then this patch is OK.

> 
> > 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
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer