Hi! I noticed the discussions about making cp-demangle use malloc/free instead of recursion, and I wonder about signal handlers, and I don't see that mentioned in https://gcc.gnu.org/wiki/SummerOfCode's description of the project.
See my question to Ian a few years back, here, and his answer: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00696.html ~~~ Ian says: > Pedro says: > Ian earlier mentioned that we've wanted to avoid malloc because some > programs call the demangler from a signal handler, but it seems like > we already do, these functions already aren't safe to use from > signal handlers as is. Where does the "we can't use malloc" idea > come from? Is there some entry point that avoids > the malloc/realloc/free calls? cplus_demangle_v3_callback and cplus_demangle_print_callback. ~~~ Grepping the gcc tree, I see that libsanitizer uses those entry points. Is async-signal safety no longer a consideration/concern? Or will those entry points continue to work without calling malloc/free somehow?
