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


Reply via email to