[Bug c/108694] need a new warning option for preparing migration to ISO C 23

2023-02-07 Thread bruno at clisp dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694

--- Comment #4 from Bruno Haible  ---
(In reply to Aaron Ballman from comment #3)
OK. So, except for this unlucky (*) choice of attribution in case of a conflict
between function declaration and function definition, the
'-Wdeprecated-non-prototype' warning is actually usable.

What we need is thus:
* -Wdeprecated-non-prototype,
* combined with a kind of -Wfuture-incompatible-function-pointer-types, that
considers the interpretation according to C23 instead of the interpretation
according to the currently chosen standard.

(*) Reported as a clang bug at
https://github.com/llvm/llvm-project/issues/60592 .

[Bug c/108694] need a new warning option for preparing migration to ISO C 23

2023-02-07 Thread aaron at aaronballman dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694

--- Comment #3 from Aaron Ballman  ---
(In reply to Bruno Haible from comment #2)
> But '-Wdeprecated-non-prototype' does not exactly have the behaviour you
> want: while it warns for 'func1 (1);' and 'func3 (3);' (good!), it warns
> also for 'void func3 ();', that is, where you don't want to see a warning.

FWIW, the reason you get a warning on the declaration of `func3` in Clang is
because of the definition of `func3` that is invalid in C2x but was valid in
prior standards modes. If you do not provide a problematic conflicting
definition, the diagnostic is silenced: https://godbolt.org/z/aMPrvWz1j

[Bug c/108694] need a new warning option for preparing migration to ISO C 23

2023-02-07 Thread bruno at clisp dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694

--- Comment #2 from Bruno Haible  ---
(In reply to Florian Weimer from comment #1)
> “()” is going to be fine when matched with an empty parameter list in a
> definition, or an empty argument list in a call. I don't think it's
> necessary to warn in those cases. It distracts from the real issue.

OK. So let's see what we get with this approach where 'void func3 ();' doesn't
warn and only the wrong uses of func3 produce diagnostics. Here's a test case,
annotated with 'error' in those places where 'clang15 -std=c2x' produces an
error:

=
/* Function definitions: */
void func1 () {}
void func2 (void) {}
/* Function declarations: */
void func3 ();
void func4 (void);

void code ()
{
  void (*fp) (void);
  void (*fp1) (int);

  fp = func1;
  fp = func2;
  fp = func3;
  fp = func4;

  fp1 = func3;

  func1 (1); /* error */
  func2 (2); /* error */
  func3 (3); /* error */
  func4 (4); /* error */

  (void) fp;
  (void) fp1;
}

void func3 (int x, int y) {} /* error */
=

When compiling this in -std=c17 or older mode, we would like to get a warning
- in those places where we get an error in C23 mode, and
- in those places where there are unsafe conversions or parameter passing going
on in C23 or in C17 or older.
In detail, the desired behaviour in -std=c17 or older mode is:

=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* No warning */
void func4 (void); /* No warning */

void code ()
{
  void (*fp) (void);
  void (*fp1) (int);

  fp = func1; /* No warning */
  fp = func2; /* No warning */
  fp = func3; /* No warning */
  fp = func4; /* No warning */

  fp1 = func3; /* warning */

  func1 (1); /* warning (if -std=c17) or error (if -std=c23) */
  func2 (2); /* error */
  func3 (3); /* warning (if -std=c17) or error (if -std=c23) */
  func4 (4); /* error */

  (void) fp;
  (void) fp1;
}

void func3 (int x, int y) {} /* warning (if -std=c17) or error (if -std=c23) */
=

In the line 'fp1 = func3;' a warning should be shown because it's an unsafe
function pointer conversion in C23. (Even though in C17 it is not dangerous
code and even though in C23 it's not an error!) 'clang15 -std=c2x
-Wincompatible-function-pointer-types' does show a "warning: incompatible
function pointer types" there.

> Clang now has -Wdeprecated-non-prototype apparently

But '-Wdeprecated-non-prototype' does not exactly have the behaviour you want:
while it warns for 'func1 (1);' and 'func3 (3);' (good!), it warns also for
'void func3 ();', that is, where you don't want to see a warning.

So, no existing GCC or clang warning option has the desired behaviour. What we
need (and even independently of programming style) is
* a part of -Wdeprecated-non-prototype: do warn in function call positions,
don't warn in function declaration/type positions,
* combined with a kind of -Wfuture-incompatible-function-pointer-types, that
considers the interpretation according to C23 instead of the interpretation
according to the currently chosen standard.

[Bug c/108694] need a new warning option for preparing migration to ISO C 23

2023-02-07 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694

Andrew Pinski  changed:

   What|Removed |Added

 Target|x86_64-linux-gnu|
   Host|x86_64-linux-gnu|
  Build|x86_64-linux-gnu|
   Severity|normal  |enhancement

[Bug c/108694] need a new warning option for preparing migration to ISO C 23

2023-02-07 Thread fw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #1 from Florian Weimer  ---
Clang now has -Wdeprecated-non-prototype apparently:
https://discourse.llvm.org/t/unresolved-issues-from-the-llvm-15-x-release/66071/36

This is probably not very useful as a warning:

> void func3 (); /* warning: an empty parameter list in function declarators 
> will have a different meaning in ISO C23 */

“()” is going to be fine when matched with an empty parameter list in a
definition, or an empty argument list in a call. I don't think it's necessary
to warn in those cases. It distracts from the real issue.