On Mon, Sep 8, 2025 at 4:24 PM Kees Cook <k...@kernel.org> wrote:
>
> On Tue, Sep 09, 2025 at 12:13:19AM +0200, Martin Uecker wrote:
> > Sorry, example should have been this:
> >
> > typedef int arr_t[];
> > typedef int arr3_t[3];
> >
> > void f(arr3_t*);
> >
> > void g(void (*fp)(arr_t*)) {
> >
> > int a[3];
> > (*fp)(&a); // this call would fail?
> > }
> >
> > int h()
> > {
> > g(&f);
> > }
>
> Yes, that would fail. It's a pointer to an array of 3 ints, and that's
> fine for distinguishing mismatched callers:
>
> void(arr3_t*) -> void(int(*)[3]) -> _ZTSFvPA3_iE
> void(arr_t*) -> void(int(*)[]) -> _ZTSFvPA_iE
>
> How should I adjust this patch's description to say the mangling may
> follow a stricter type system?
Maybe it is time to step back for a second and figure out other things
are not going to work with this mangling scheme? At the bare minimum
write down limitations to the user documentation (and write up a bug
report to LLVM for them to do the same).
Or even better step back and fix the hashing scheme to fit better with
C rather than reusing IA64 C++ ABI mangling (which is not designed for
C). If we need a hard ABI break due to limitations, it is good to do
it now rather than having 2 different implementations that need to
change upstream; right now you only need to break LLVM's ABI.
Thanks,
Andrew Pinski
