On Mon, Dec 10, 2018 at 1:55 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Mon, Dec 10, 2018 at 10:20:24AM -0800, Ian Lance Taylor wrote: > > > I think it is a bad idea to use the same macro and value for both the > > > recursion limit and essentially stack limit. For the latter, it should > > > actually compute expected stack size > > > (i.e. di.num_comps * sizeof (*di.comps) + di.num_subs * sizeof (*di.subs)) > > > and rather than just giving up should say that memory up to 64KB this > > > way will be handled via alloca, more through say mmap (I'd avoid malloc > > > because some users are using these APIs in cases where malloc isn't > > > usable). > > > And have only much larger limit, like say 1MB for these arrays on which to > > > give up. > > > > That makes sense. > > > > We've wanted to avoid malloc in this code because some programs call > > the demangler from a signal handler. But using mmap should be fine in > > practice. > > mmap is not available everywhere, but we could just have a smaller limit > on how big mangled names we handle on targets where mmap isn't available or > if it fails. > > And, the other option is just try to parse the string without doing all the > processing first and compute (perhaps upper bound) on how many components > and substitutions we need. Many components have longish names, or numbers, > etc. so the 2 * strlen is really very upper bound and strlen for number of > substitutions too.
Or, in that situation, we could put an upper bound on the number of components and substitutions, and fail if we end up needing more than that. Jason
