On Fri, Dec 12, 2025 at 5:24 PM Kees Cook <[email protected]> wrote: > > On Fri, Dec 12, 2025 at 03:07:51PM -0800, Andrew Pinski wrote: > > On Tue, Dec 9, 2025 at 6:27 PM Kees Cook <[email protected]> wrote: > > [...] > > > +uint32_t > > > +typeinfo_get_hash (tree type) > > > +{ > > > + gcc_assert (type != NULL_TREE); > > > + uint32_t hash_state = 2166136261U; /* FNV-1a 32-bit offset basis. */ > > > + > > > + mangle_type (type, nullptr, &hash_state); > > > + return hash_state; > > > +} > > > > It might make sense to do a few self_test here instead of (in addition > > to) having a testcase. > > This way the testing is done earlier. > > I tried to do this back in v2 and could not make it work. See [1] for > more details on what I found, but basically I don't have access to the > parser itself in the selftests, so I couldn't build end-to-end testing > of arbitrary C (testing node types isn't really a sufficient test in my > view). I could to basic type tests, but it would be redundant to what > I ended up with in dg, and I didn't want to split up the testing.
I am asking for self-tests of the API and not depending on the C parser. So generating some FUNCTION_TYPE types and then getting back the hash and/or name. > (testing node types isn't really a sufficient test in my view) It might not be a fully sufficient test in itself; it does not mean it is NOT a useful test to have. This is why I mentioned in addition to. Testing the API outside of the end-to-end testing is a good thing and can find bugs early on. GCC does not have enough self-tests really and folks don't use it as much as we should. Thanks, Andrew Pinski > > If I'm missing some other way to do this, I'd be happy to give it a shot! > > -Kees > > [1] > https://lore.kernel.org/linux-hardening/[email protected]/ > > -- > Kees Cook
