This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


On Mon, 2018-12-10 at 14:52 +0000, Michael Matz wrote:
> Hi,
> On Fri, 7 Dec 2018, H.J. Lu wrote:
> > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton <>
> > > > wrote:
> > > > > 
> > > > >   Is the patch OK with you ?
> > > 
> > > This caused:
> > > 
> > >
> > > 
> > 
> > Here is the fix.   OK for trunk?
> I think this points toward the limit being _much_ too low.  With
> template 
> meta programming you easily get these mangled names, it's not even a 
> particularly long one.  But I'm wondering a bit, without tracing the 
> demangler, just looking at the symbol name and demangled result I
> don't 
> readily see where the depth of recursion really is more than 1024,
> are 
> there perhaps some recursion_level-- statements skipped?

Apologies in advance if this has been covered, as I've only been half-
watching this thread, but is it always the case that the recursion
depth can be bounded by some scalar multiple of the number of
characters in the name?

The name that's causing trouble is 654 characters long, and the
proposed limit of 1306 is slightly below double that.  There may well
be a bug in the implementation as Michael points out, but is the
recursion depth always guaranteed to be less than 2 * num_chars seen,
or somesuch limit.  If so, could the limit be dynamic, rather than
hardcoded?  That would trap cases where we're consuming stack frames
without consuming input characters, and eliminate having a hardcoded
limit that's bound to eventually become wrong as people write more and
more complicated C++ programs.

Hope this is constructive

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]