Jakub Jelinek wrote: > cp-demangle.c isn't used just in libiberty, where using hashtab, > xcalloc, XNEW etc. is fine, but also in libsupc++/libstdc++, where > none of that is fine. That is why cp-demangle.c only uses > e.g. realloc, checks for allocation failures and propagates those to > the caller if they happen (see allocation_failure field). hashtab.o > isn't linked into libstdc++ nor libsupc++, and the question is if we > really do want to link all the hashtable code into libstdc++. > How many hash table entries are there typically? Is a hashtable > required?
Three entries were required for the symbol in the testcase: "_ZSt7forwardIRN1x14refobjiteratorINS0_3refINS0_4mime30multipart_se" \ "ction_processorObjIZ15get_body_parserIZZN14mime_processor21make_se" \ "ction_iteratorERKNS2_INS3_10sectionObjENS0_10ptrrefBaseEEEbENKUlvE" \ "_clEvEUlSB_bE_ZZNS6_21make_section_iteratorESB_bENKSC_clEvEUlSB_E0" \ "_ENS1_INS2_INS0_20outputrefiteratorObjIiEES8_EEEERKSsSB_OT_OT0_EUl" \ "mE_NS3_32make_multipart_default_discarderISP_EEEES8_EEEEEOT_RNSt16" \ "remove_referenceISW_E4typeE" I don't think there will many symbols with very many entries required. I'm guessing that most symbols will require zero (which is why I made it defer hashtable creation until it was required). What kind of data structure would you like to see here, a realloc'd array? Do libsupc++ and libstdc++ use the demangler for anything more performance-sensitive than exception printing? Thanks, Gary -- http://gbenson.net/
