Why bug 1289455 removed manual CERT_DestroyCertificate calls in favor of UniqueCERTCertificate, one non-obvious side effect was to make |struct nsMyTrustedEVInfo| in ExtendedValidation.cpp a non-POD structure, as UniqueCERTCertificate has user-defined constructors. On some compilers, this change causes a static constructor to be generated for the myTrustedEVInfos array. On x86-64 Linux, for instance, we have a 24K function just to initialize the array: 385: 0000000000000000 23674 FUNC LOCAL DEFAULT 540 _GLOBAL__sub_I_Unified_cpp_certverifier0.cpp (This is partly because the code to initialize the array is completely awful, but still.) It would be really nice if we didn't have to do this. Unfortunately, the usual trick that I turn to in this situation (constexpr constructors for the non-POD thing in question) doesn't seem to work; GCC still generates a static constructor. The other alternative I thought of was to have two arrays, one with all the constant information (oid bits, fingerprint, base64 pointers), and then the certs can be stored off to the side in a separate array. The separate array should at least result in a smaller static constructor. It makes the code a bit more complicated, but maybe that's acceptable here. Bug 1289455 comment 2 sounds like we don't even need to store the certificate in this array, but I don't know how to do that--but am willing to try with appropriate help. David: thoughts, ideas?
(In reply to Nathan Froyd [:froydnj] from comment #0) > Bug 1289455 comment 2 sounds like we don't even need to store the certificate in this array, but > I don't know how to do that--but am willing to try with appropriate help. FWIW, I have a WIP attached to Bug 1296214 that implements this (I should've mentioned the bug number in Bug 1289455, but oh well). I can drive it to completion if it solves this bug.
froydnj: Is this fixed now that Bug 1296214 is?
(In reply to :Cykesiopka from comment #3) > froydnj: Is this fixed now that Bug 1296214 is? This is! Thank you for finishing off that bug.