Am Dienstag, dem 09.09.2025 um 09:33 -0700 schrieb Kees Cook: >
> > > > One thing for sure we need to settle on is a common hash and (AIUI) > > > LLVM would like to drop the hash KCFI is currently using (KCFI is the > > > last user of it). As I mentioned elsewhere, the hash doesn't need to be > > > cryptographically secure, so FNV-1a could very well be sufficient. > > > > > > As for https://github.com/llvm/llvm-project/issues/106593, my GCC > > > implementation actually doesn't exhibit this behavior since it uses the > > > typedef name instead already (I had other places where the behavior was > > > mismatched and the logic I ended up with turned out to be slightly more > > > generalized than LLVM's). (I will need to fix this in LLVM.) I test for > > > it in the type mangling tests already: > > > > Note that is also not entirely correct for C. It is allowed > > to call this via different typedef names across TU, > > > > > > It would be possible to normalize the type before (or during) mangling > > in a way that it works correctly for all C ta cost of precision. > > > > I think this would be desirable because otherwise this could cause > > surprises for users, and with it conforming to C, it could be used > > more easily also by other projects. > > We want to be able to distinguish separate function types which may be > more strict than "conforming C" (e.g. enum vs int: we _want_ this to be > a mismatch.) > > > The cost is that is a bit less precise. > > This isn't a feature someone just slaps in place and runs away from. :) > We spent literal years getting Linux's function prototypes sorted out. > There was a lot of mess that needed cleaning up. Maybe there should be flag to select between a strict mode that differentiates between enums / int etc. and a fully standard-compliant mode that accepts all legal C code. Not saying that you have to implement it. For example, I could probably add this later, if this of interest to others as well. Martin
