On Tue, 2025-01-14 at 00:08 +0000, Joseph Myers wrote: > On Sun, 12 Jan 2025, David Malcolm wrote: > > > So I've dropped the takes_int_p, takes_void_p, and > > maybe_inform_empty_args_c23_transition from the patch. Here's an > > updated version that keeps the rest of the changes. I'd like to > > get > > this into GCC 15 to make build failures due to C23- > > incompatibilities > > more readable. > > Some comments in testcases still repeat the misconception about > implicit > (int) for unprototyped functions. > > OK with that fixed. > > > diff --git a/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr- > > alsatools.c b/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr- > > alsatools.c > > new file mode 100644 > > index 000000000000..e3460e546a9a > > --- /dev/null > > +++ b/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr-alsatools.c > > @@ -0,0 +1,21 @@ > > +/* Examples of a mismatching function pointer types in > > + legacy code compiled with C23 that assumed () meant (int). > > This comment is incorrect, unprototyped is not (int). > > > diff --git a/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr.c > > b/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr.c > > new file mode 100644 > > index 000000000000..4db44f48a3f2 > > --- /dev/null > > +++ b/gcc/testsuite/gcc.dg/c23-mismatching-fn-ptr.c > > @@ -0,0 +1,76 @@ > > +/* Verify that when we complain about incompatible pointer types > > + involving function pointers, we show the declaration of the > > + function. > > + > > + In particular, check the case of > > + extern void fn (); > > + changing meaning in C23 (from taking int to taking void). */ > > Likewise. > > > +/* Test of storing a sighandler_t where the declaration of the > > + destination might be relying on implicit int arg, which > > + becomes void in C23. > > Likewise.
Thanks. I removed the bad wording in the comments, and have pushed it as r15-6886-gbbc7900ce7e2c3. Dave
