Update on the Modern C initiative

[Florian Weimer]

This message is realted to:

  <https://fedoraproject.org/wiki/Changes/PortingToModernC>
  <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>

The final patches for GCC 14 are currently under upstream review and
should land very soon.  Earlier, I had received feedback that the larger
community desires just one transition, so we end up with the following
warnings which turn into errors by default:

  -Wimplicit-function-declaration
  -Wimplicit-int
  -Wint-conversion
  -Wreturn-mismatch (new, previously part of -Wreturn-types)
  -Wdeclaration-missing-parameter-type (new, previously unnamed)
  -Wincompatible-pointer-types

Only the first two were covered in the initial Fedora conversion work.

I've done another round of test builds with an instrumented GCC for all
errors, and the numbers of problematic packages I have today are:

                                          autoconf
                                      all     only
  implicit-function-declaration        53       21
  implicit-int                          2        0
  int-conversion                       99       33
  return-mismatch                      13        2
  declaration-missing-parameter-type    0        0
  incompatible-pointer-types          374       50
                                      487       89

(I've updated the change page to describe those diagnostics briefly.)

The numbers don't add up because one package can have multiple issues.
Some of the reported issues are false positives, although the GCC
instrumentation is a bit better than it used to be.

The autoconf column covers packages which are particularly at risk for
silent miscompilation because of incorrect detection of build system
features.  This is based on file name heuristics and includes more than
just autoconf proper.

As you can see, the incompatible-pointer-types issues are a bit of a
problem.  We fixed over 800 packages during the first round, and now it
looks like we are only two thirds done.

It is unlikely that I will be able to work on all these issues
myself or with help from the people around me.  I just suggested to GCC
upstream that we may have to reconsider including this change in the GCC
14 release.

Consequently, my priorities are as follows:

* Try to resolve the autoconf issues in packages, to reduce the risk of
  silent miscompilation.

* Integrate a backport of the GCC 14 changes into the rawhide GCC 13
  version (rawhide only, not Fedora 39 or 38).  This will allow us
  to isolate these issues from GCC 14 issues that typically occur
  during the upcoming mass rebuild.

* Produce the final redhat-rpm-config integration, using -fpermissive
  for _build_type_safety_c 0, and -Wno-error= options for the higher
  type safety levels.  This obviously depends on -fpermissive and and
  the new warning names becoming available in rawhide, which is another
  reason for the GCC 13 backport.

* Come up with a way to resolve the Vala situation, likely by embedded
  “#pragma GCC diagnostic” in the generated C source files.  Vala is
  currently not able to generate type-safe C, and is unlikely that this
  going to change soon.  (The numbers above do not include packages
  which have failures in Vala code only.)  In some cases, there is
  nothing that can be done about this on the Vala source code side.  Not
  all of these type errors are harmless, of course, but I don't see a
  way to deal with this except by telling GCC to be less picky.

I'm attaching package maintainer lists, generated using the
find-package-maintainers script from fthe
<https://pagure.io/fedora-misc-package-utilities/> repository, for both
the full package set, and the autoconf-impacted package set.

Build logs with results from the instrumentation are available here;

  <https://gitlab.com/fweimer-rh/fedora-modernc-logs/>

We delete logs from that repository as packages get fixed.

Again, some of these are false positives.  The second link at the start
has instructions for a COPR repository if you want to verify things
locally (sadly the Koji build target is currently not in working order).

Thanks,
Florian

[Vít Ondruch]

Dne 30. 11. 23 v 18:09 Florian Weimer napsal(a):
>  This message is realted to:
>
>     <https://fedoraproject.org/wiki/Changes/PortingToModernC>
>     <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>
>
>  The final patches for GCC 14 are currently under upstream review and
>  should land very soon.  Earlier, I had received feedback that the larger
>  community desires just one transition, so we end up with the following
>  warnings which turn into errors by default:
>
>     -Wimplicit-function-declaration
>     -Wimplicit-int
>     -Wint-conversion
>     -Wreturn-mismatch (new, previously part of -Wreturn-types)
>     -Wdeclaration-missing-parameter-type (new, previously unnamed)
>     -Wincompatible-pointer-types
>
>  Only the first two were covered in the initial Fedora conversion work.
>
>  I've done another round of test builds with an instrumented GCC for all
>  errors, and the numbers of problematic packages I have today are:
>
>                                             autoconf
>                                         all     only
>     implicit-function-declaration        53       21
>     implicit-int                          2        0
>     int-conversion                       99       33
>     return-mismatch                      13        2
>     declaration-missing-parameter-type    0        0
>     incompatible-pointer-types          374       50
>                                         487       89
>
>  (I've updated the change page to describe those diagnostics briefly.)
>
>  The numbers don't add up because one package can have multiple issues.
>  Some of the reported issues are false positives, although the GCC
>  instrumentation is a bit better than it used to be.
>
>  The autoconf column covers packages which are particularly at risk for
>  silent miscompilation because of incorrect detection of build system
>  features.  This is based on file name heuristics and includes more than
>  just autoconf proper.
>
>  As you can see, the incompatible-pointer-types issues are a bit of a
>  problem.  We fixed over 800 packages during the first round, and now it
>  looks like we are only two thirds done.
>
>  It is unlikely that I will be able to work on all these issues
>  myself or with help from the people around me.  I just suggested to GCC
>  upstream that we may have to reconsider including this change in the GCC
>  14 release.
>
>  Consequently, my priorities are as follows:
>
>  * Try to resolve the autoconf issues in packages, to reduce the risk of
>     silent miscompilation.
>
>  * Integrate a backport of the GCC 14 changes into the rawhide GCC 13
>     version (rawhide only, not Fedora 39 or 38).  This will allow us
>     to isolate these issues from GCC 14 issues that typically occur
>     during the upcoming mass rebuild.
>
>  * Produce the final redhat-rpm-config integration, using -fpermissive
>     for _build_type_safety_c 0, and -Wno-error= options for the higher
>     type safety levels.  This obviously depends on -fpermissive and and
>     the new warning names becoming available in rawhide, which is another
>     reason for the GCC 13 backport.
>
>  * Come up with a way to resolve the Vala situation, likely by embedded
>     “#pragma GCC diagnostic” in the generated C source files.  Vala is
>     currently not able to generate type-safe C, and is unlikely that this
>     going to change soon.  (The numbers above do not include packages
>     which have failures in Vala code only.)  In some cases, there is
>     nothing that can be done about this on the Vala source code side.  Not
>     all of these type errors are harmless, of course, but I don't see a
>     way to deal with this except by telling GCC to be less picky.
>
>  I'm attaching package maintainer lists, generated using the
>  find-package-maintainers script from fthe
>  <https://pagure.io/fedora-misc-package-utilities/> repository, for both
>  the full package set, and the autoconf-impacted package set.
>
>  Build logs with results from the instrumentation are available here;
>
>     <https://gitlab.com/fweimer-rh/fedora-modernc-logs/>
>
>  We delete logs from that repository as packages get fixed.
>  

How often this happens? It seems that there might be upstream fix for 
rubygem-curb, so if I update the package, how soon I'll know it helped?

Thx


Vít


>  Again, some of these are false positives.  The second link at the start
>  has instructions for a COPR repository if you want to verify things
>  locally (sadly the Koji build target is currently not in working order).
>
>  Thanks,
>  Florian
>
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Florian Weimer]

* Vít Ondruch:

> > Build logs with results from the instrumentation are available
> here;
> >
> >    <https://gitlab.com/fweimer-rh/fedora-modernc-logs/>
> >
> > We delete logs from that repository as packages get fixed.
>
>
>  How often this happens? It seems that there might be upstream fix for
>  rubygem-curb, so if I update the package, how soon I'll know it
>  helped? 
You can build against the COPR repository to test:

 
<https://fedoraproject.org/wiki/Toolchain/PortingToModernC#Special_COPR_re...

I don't have a rechecking schedule, it depends on whether I find a way
to improve the GCC instrumentation.

Thanks,
Florian

[Milan Crha]

On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
>  Again, some of these are false positives.  
	Hi,
I think the errors from the configure time of the script are not always
problems, are they? At least in the case of the evolution-data-server,
it's half a problem and half expected.

Specifically, one "configure" (there is used CMake) check tries to
figure out whether gethostbyname_r() has five arguments. It does not in
Fedora, thus a) there are passed no enough arguments to the function;
b) there are incompatible types passed to the function. Both are
claimed by gcc. The second is due to the first. The result of this
"source compiles" test is correct, the function does not have five
arguments.

Another "configure" check used incorrect arguments in error. I
corrected it for the development version [1], which should be released
at the beginning of the next year.

I can workaround the first problem by doing the check only when needed,
but I do not think tests like these are supposed to not break.

	Bye,
	Milan

[1]
https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/55558d3c23e...

[Vít Ondruch]

Dne 01. 12. 23 v 11:40 Milan Crha napsal(a):
>  On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
> > Again, some of these are false positives.
>  	Hi,
>  I think the errors from the configure time of the script are not always
>  problems, are they?
>  

This probably falls into the configuration bucket:

https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/blob/main/logs/r/ruby...

But I don't even know where GCC digs up the issues.



Vít


>    At least in the case of the evolution-data-server,
>  it's half a problem and half expected.
>
>  Specifically, one "configure" (there is used CMake) check tries to
>  figure out whether gethostbyname_r() has five arguments. It does not in
>  Fedora, thus a) there are passed no enough arguments to the function;
>  b) there are incompatible types passed to the function. Both are
>  claimed by gcc. The second is due to the first. The result of this
>  "source compiles" test is correct, the function does not have five
>  arguments.
>
>  Another "configure" check used incorrect arguments in error. I
>  corrected it for the development version [1], which should be released
>  at the beginning of the next year.
>
>  I can workaround the first problem by doing the check only when needed,
>  but I do not think tests like these are supposed to not break.
>
>  	Bye,
>  	Milan
>
>  [1]
> https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/55558d3c23e...
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Florian Weimer]

* Vít Ondruch:

>  Dne 01. 12. 23 v 11:40 Milan Crha napsal(a):
> > On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
> >> Again, some of these are false positives.
> > 	Hi,
> > I think the errors from the configure time of the script are not always
> > problems, are they?
>
>
>  This probably falls into the configuration bucket:
>
>
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/blob/main/logs/r/ruby...
>
>  But I don't even know where GCC digs up the issues. 
It looks like the GCC output lands in this file:

ruby-libvirt-0.7.1/usr/lib64/gems/ruby/ruby-libvirt-0.7.1/mkmf.log

I have not seen that one before, so the log dumper in the buildroot
instrumentation does not cover it, sorry.

The failures look like this:

“
LD_LIBRARY_PATH=.:/usr/lib64 "gcc -I/usr/include -I/usr/include/ruby/backward
-I/usr/include -I.     -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Werror=implicit-function-declaration -Werror=implicit-int
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -fPIC  -m64  -c conftest.c"
conftest.c:8:16: error: initialization of ‘int’ from ‘char *’ makes integer from pointer
without a cast
    8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/libvirt/libvirt.h:35,
                 from conftest.c:5:
conftest.c:8:16: error: initializer element is not computable at load time
    8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
      |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
conftest.c:8:12: warning: ‘t’ defined but not used [-Wunused-variable]
    8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
      |            ^
checked program was:
/* begin */
1: #include "ruby.h"
2: 
3: #include "ruby.h"
4: 
5: #include <libvirt/libvirt.h>
6: 
7: /*top*/
8: static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
/* end */
”

Looking at the Ruby MakeMakefile documention:

<https://docs.ruby-lang.org/en/master/MakeMakefile.html#method-i-have_cons...

I think you need to supply a type for these constants and call
have_const like this:

  have_const(["VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES",
              "const char *"], ["libvirt/virterror.h"])

Does this help?  I'm not a Ruby programmer, so I'm not even sure if I
got the list syntax right …

Thanks,
Florian

[Vít Ondruch]

Dne 02. 12. 23 v 17:42 Florian Weimer napsal(a):
>  * Vít Ondruch:
>
> > Dne 01. 12. 23 v 11:40 Milan Crha napsal(a):
> >> On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
> >>> Again, some of these are false positives.
> >> 	Hi,
> >> I think the errors from the configure time of the script are not always
> >> problems, are they?
> >
> > This probably falls into the configuration bucket:
> >
> >
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/blob/main/logs/r/ruby...
> >
> > But I don't even know where GCC digs up the issues.
>  It looks like the GCC output lands in this file:
>
>  ruby-libvirt-0.7.1/usr/lib64/gems/ruby/ruby-libvirt-0.7.1/mkmf.log
>
>  I have not seen that one before, so the log dumper in the buildroot
>  instrumentation does not cover it, sorry.
>
>  The failures look like this:
>
>  “
>  LD_LIBRARY_PATH=.:/usr/lib64 "gcc -I/usr/include -I/usr/include/ruby/backward
> -I/usr/include -I.     -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -fPIC  -m64  -c conftest.c"
>  conftest.c:8:16: error: initialization of ‘int’ from ‘char *’ makes integer from pointer
> without a cast
>       8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>         |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  In file included from /usr/include/libvirt/libvirt.h:35,
>                    from conftest.c:5:
>  conftest.c:8:16: error: initializer element is not computable at load time
>       8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>         |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  conftest.c:8:12: warning: ‘t’ defined but not used [-Wunused-variable]
>       8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>         |            ^
>  checked program was:
>  /* begin */
>  1: #include "ruby.h"
>  2:
>  3: #include "ruby.h"
>  4:
>  5: #include <libvirt/libvirt.h>
>  6:
>  7: /*top*/
>  8: static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>  /* end */
>  ”
>
>  Looking at the Ruby MakeMakefile documention:
>
>  <https://docs.ruby-lang.org/en/master/MakeMakefile.html#method-i-have_cons...
>
>  I think you need to supply a type for these constants and call
>  have_const like this:
>
>     have_const(["VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES",
>                 "const char *"], ["libvirt/virterror.h"])
>
>  Does this help?  I'm not a Ruby programmer, so I'm not even sure if I
>  got the list syntax right …
>  

Forwarded to upstream:

https://gitlab.com/libvirt/libvirt-ruby/-/issues/8

I'll look again into this unless I hear back from upstream.


Vít


>  Thanks,
>  Florian
>
>

[Daniel P. Berrangé]

On Sat, Dec 02, 2023 at 05:42:11PM +0100, Florian Weimer wrote:
>  * Vít Ondruch:
>  
>  > Dne 01. 12. 23 v 11:40 Milan Crha napsal(a):
>  >> On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
>  >>> Again, some of these are false positives.
>  >> 	Hi,
>  >> I think the errors from the configure time of the script are not always
>  >> problems, are they?
>  >
>  >
>  > This probably falls into the configuration bucket:
>  >
>  >
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/blob/main/logs/r/ruby...
>  >
>  > But I don't even know where GCC digs up the issues.
>  
>  It looks like the GCC output lands in this file:
>  
>  ruby-libvirt-0.7.1/usr/lib64/gems/ruby/ruby-libvirt-0.7.1/mkmf.log
>  
>  I have not seen that one before, so the log dumper in the buildroot
>  instrumentation does not cover it, sorry.
>  
>  The failures look like this:
>  
>  “
>  LD_LIBRARY_PATH=.:/usr/lib64 "gcc -I/usr/include -I/usr/include/ruby/backward
> -I/usr/include -I.     -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -fPIC  -m64  -c conftest.c"
>  conftest.c:8:16: error: initialization of ‘int’ from ‘char *’ makes integer from pointer
> without a cast
>      8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>        |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  In file included from /usr/include/libvirt/libvirt.h:35,
>                   from conftest.c:5:
>  conftest.c:8:16: error: initializer element is not computable at load time
>      8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>        |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  conftest.c:8:12: warning: ‘t’ defined but not used [-Wunused-variable]
>      8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>        |            ^
>  checked program was:
>  /* begin */
>  1: #include "ruby.h"
>  2: 
>  3: #include "ruby.h"
>  4: 
>  5: #include <libvirt/libvirt.h>
>  6: 
>  7: /*top*/
>  8: static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>  /* end */
>  ”
>  
>  Looking at the Ruby MakeMakefile documention:
>  
>  <https://docs.ruby-lang.org/en/master/MakeMakefile.html#method-i-have_cons...
>  
>  I think you need to supply a type for these constants and call
>  have_const like this:
>  
>    have_const(["VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES",
>                "const char *"], ["libvirt/virterror.h"])
>  
>  Does this help?  I'm not a Ruby programmer, so I'm not even sure if I
>  got the list syntax right … 
Thanks, it turns out these checks are really terribly obsolete. Checking
for existence of features that have been around for 10 years, so I'm
proposing to kill them all upstream and we'll get this into rawhide
after that.

  https://gitlab.com/libvirt/libvirt-ruby/-/merge_requests/28

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Florian Weimer]

* Milan Crha:

>  On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
> > Again, some of these are false positives. 
>
>  	Hi,
>  I think the errors from the configure time of the script are not always
>  problems, are they? At least in the case of the evolution-data-server,
>  it's half a problem and half expected. 
Yes, we have definitely need an exception list for implicit function
declarations.

>  Specifically, one "configure" (there is used CMake) check
> tries to
>  figure out whether gethostbyname_r() has five arguments. It does not in
>  Fedora, thus a) there are passed no enough arguments to the function;
>  b) there are incompatible types passed to the function. Both are
>  claimed by gcc. The second is due to the first. The result of this
>  "source compiles" test is correct, the function does not have five
>  arguments. 
I don't see this.  The evolution-data-server-3.50.2-1.fc39 and
evolution-data-server-3.50.2-1.fc40 have this:

-- Performing Test HAVE_I_CAL_EMAIL_PARAMETER
-- Performing Test HAVE_I_CAL_EMAIL_PARAMETER - Success

While my test build has:

-- Performing Test HAVE_I_CAL_EMAIL_PARAMETER
-- Performing Test HAVE_I_CAL_EMAIL_PARAMETER - Failed

So the test outcome is altered by the new error.

Furthermore, in the YAML log, I don't see the second error about the
mismatching parameter count:

“
…-build/CMakeFiles/CMakeScratch/TryCompile-HmYCHv/src.c: In function ‘main’:
…-build/CMakeFiles/CMakeScratch/TryCompile-HmYCHv/src.c:5:39: error: assignment to
‘icalparameter *’ {aka ‘struct icalparameter_impl *’} from incompatible pointer type
‘ICalParameter *’
    5 |                                 param = i_cal_property_get_first_parameter (NULL,
I_CAL_EMAIL_PARAMETER);
      |                                       ^
…-build/CMakeFiles/CMakeScratch/TryCompile-HmYCHv/src.c:6:60: error: passing argument 1 of
‘i_cal_parameter_get_email’ from incompatible pointer type
    6 |                                 i_cal_parameter_get_email (param);
      |                                                            ^~~~~
      |                                                            |
      |                                                            icalparameter * {aka
struct icalparameter_impl *}
In file included from /usr/include/libical-glib/i-cal-parameter.h:28,
                 from /usr/include/libical-glib/i-cal-component.h:27,
                 from /usr/include/libical-glib/libical-glib.h:34,
                 from …-build/CMakeFiles/CMakeScratch/TryCompile-HmYCHv/src.c:2:
/usr/include/libical-glib/i-cal-derived-parameter.h:399:71: note: expected ‘const
ICalParameter *’ but argument is of type ‘icalparameter *’ {aka ‘struct icalparameter_impl
*’}
          399 | const gchar *   i_cal_parameter_get_email       (const ICalParameter
*param);
              |                                                 
~~~~~~~~~~~~~~~~~~~~~^~~~~
”

The instrumented GCC can backpropagate certain errors and suppress the
logging of otherwise critical errors (even if they occurred earlier in
the file), including in some cases if there are too many function
arguments.  However, this suppression heuristic is presently incomplete.
But I don't think it matters here because there is no such error in the
CMake probe.

>  Another "configure" check used incorrect arguments in
> error. I
>  corrected it for the development version [1], which should be released
>  at the beginning of the next year. 
>  [1]
> https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/55558d3c23e...
Ahh, sorry, I think I looked at this error because that's the only one
that makes it into the critical error log. 8-)

The first one you mentioned has probably been suppressed by the
heuristic.  Still sending this message because it might be helpful to
show how this works.

Thanks,
Florian

[Milan Crha]

On Sat, 2023-12-02 at 17:33 +0100, Florian Weimer wrote:
>  > Specifically, one "configure" (there is used CMake)
> check tries to
>  > figure out whether gethostbyname_r() has five arguments. It does
>  > not in
>  > Fedora, thus a) there are passed no enough arguments to the
>  > function;
>  > b) there are incompatible types passed to the function. Both are
>  > claimed by gcc. The second is due to the first. The result of this
>  > "source compiles" test is correct, the function does not have five
>  > arguments.
>  
>  I don't see this.  The evolution-data-server-3.50.2-1.fc39 and
>  evolution-data-server-3.50.2-1.fc40 have this:
>  
>  -- Performing Test HAVE_I_CAL_EMAIL_PARAMETER
>  -- Performing Test HAVE_I_CAL_EMAIL_PARAMETER - Success
>  
>  While my test build has:
>  
>  -- Performing Test HAVE_I_CAL_EMAIL_PARAMETER
>  -- Performing Test HAVE_I_CAL_EMAIL_PARAMETER - Failed
>  
>  So the test outcome is altered by the new error. 
	Hi,
the HAVE_I_CAL_EMAIL_PARAMETER is the b) from the above, aka the
changes uncovered a bug in the configure-time code-compiles check.

The a), an expected failure, is this one:
     .../TryCompile-0C2YRH/src.c: In function ‘main’:
     .../TryCompile-0C2YRH/src.c:11:37: warning: redundant redeclaration of
‘__h_errno_location’ [-Wredundant-decls]
        11 |                                 int h_errno;
           |                                     ^~~~~~~
     /usr/include/netdb.h:59:13: note: previous declaration of ‘__h_errno_location’ with
type ‘int *(void)’
        59 | extern int *__h_errno_location (void) __THROW __attribute__ ((__const__));
           |             ^~~~~~~~~~~~~~~~~~
     .../TryCompile-0C2YRH/src.c:12:111: warning: passing argument 7 of ‘gethostbyaddr_r’
from incompatible pointer type [-Wincompatible-pointer-types]
        12 |                                 (void)gethostbyaddr_r
("www.ximian.com", 14, AF_INET, &hent, buffer, bufsize, &h_errno);
           |                                                                              
                                ^
           |                                                                              
                                |
           |                                                                              
                                int *
     /usr/include/netdb.h:174:57: note: expected ‘struct hostent ** restrict’ but argument
is of type ‘int *’
       174 |                             struct hostent **__restrict __result,
           |                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
     .../TryCompile-0C2YRH/src.c:12:39: error: too few arguments to function
‘gethostbyaddr_r’
        12 |                                 (void)gethostbyaddr_r
("www.ximian.com", 14, AF_INET, &hent, buffer, bufsize, &h_errno);
           |                                       ^~~~~~~~~~~~~~~
     /usr/include/netdb.h:170:12: note: declared here
       170 | extern int gethostbyaddr_r (const void *__restrict __addr, __socklen_t
__len,
           |            ^~~~~~~~~~~~~~~
     gmake[1]: *** [CMakeFiles/cmTC_3133a.dir/build.make:78:
CMakeFiles/cmTC_3133a.dir/src.c.o] Error 1
     gmake[1]: Leaving directory '.../TryCompile-0C2YRH'
     gmake: *** [Makefile:127: cmTC_3133a/fast] Error 2

Note the `too few arguments to function ‘gethostbyaddr_r’` error
follows the `incompatible pointer type` warning, which is going to be
an error after the proposed change.
	Bye,
	Milan

[Florian Weimer]

* Milan Crha:

>  The a), an expected failure, is this one:
>       .../TryCompile-0C2YRH/src.c: In function ‘main’:
>       .../TryCompile-0C2YRH/src.c:11:37: warning: redundant redeclaration of
> ‘__h_errno_location’ [-Wredundant-decls]
>          11 |                                 int h_errno;
>             |                                     ^~~~~~~
>       /usr/include/netdb.h:59:13: note: previous declaration of ‘__h_errno_location’ with
> type ‘int *(void)’
>          59 | extern int *__h_errno_location (void) __THROW __attribute__ ((__const__));
>             |             ^~~~~~~~~~~~~~~~~~
>       .../TryCompile-0C2YRH/src.c:12:111: warning: passing argument 7 of ‘gethostbyaddr_r’
> from incompatible pointer type [-Wincompatible-pointer-types]
>          12 |                                 (void)gethostbyaddr_r
> ("www.ximian.com", 14, AF_INET, &hent, buffer, bufsize, &h_errno);
>             |                                                                             
>                                  ^
>             |                                                                             
>                                  |
>             |                                                                             
>                                  int *
>       /usr/include/netdb.h:174:57: note: expected ‘struct hostent ** restrict’ but
> argument is of type ‘int *’
>         174 |                             struct hostent **__restrict __result,
>             |                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
>       .../TryCompile-0C2YRH/src.c:12:39: error: too few arguments to function
> ‘gethostbyaddr_r’
>          12 |                                 (void)gethostbyaddr_r
> ("www.ximian.com", 14, AF_INET, &hent, buffer, bufsize, &h_errno);
>             |                                       ^~~~~~~~~~~~~~~
>       /usr/include/netdb.h:170:12: note: declared here
>         170 | extern int gethostbyaddr_r (const void *__restrict __addr, __socklen_t
> __len,
>             |            ^~~~~~~~~~~~~~~
>       gmake[1]: *** [CMakeFiles/cmTC_3133a.dir/build.make:78:
> CMakeFiles/cmTC_3133a.dir/src.c.o] Error 1
>       gmake[1]: Leaving directory '.../TryCompile-0C2YRH'
>       gmake: *** [Makefile:127: cmTC_3133a/fast] Error 2
>
>  Note the `too few arguments to function ‘gethostbyaddr_r’` error
>  follows the `incompatible pointer type` warning, which is going to be
>  an error after the proposed change. 
No, that's actually not changing, this is already an error and will
remain an error.  Only the -Wincompatible-pointer-types warning above is
upgraded to an error, but it does not alter the outcome of this check
because there already is another error (and the current GCC
instrumentation is able to detect this an not flag the
-Wincompatible-pointer-types issue).

Thanks,
Florian

[Milan Crha]

On Mon, 2023-12-04 at 09:01 +0100, Florian Weimer wrote:
>  No, that's actually not changing, this is already an error and
> will
>  remain an error. 
	Hi,
right, the "check-compile" test is supposed to fail, thus it's fine.

>  Only the -Wincompatible-pointer-types warning above is
>  upgraded to an error, but it does not alter the outcome of this check
>  because there already is another error (and the current GCC
>  instrumentation is able to detect this an not flag the
>  -Wincompatible-pointer-types issue). 
I've been afraid you might "cancel" the whole build due to this, I
kinda expected it, because you also mentioned errors from the configure
time, but as you said it will not happen, the build can continue when a
function check fails, thus no problem so far.

Thank you for the clarification.
	Bye,
	Milan

[Richard W.M. Jones]

On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
>  * Integrate a backport of the GCC 14 changes into the rawhide GCC 13
>    version (rawhide only, not Fedora 39 or 38).  This will allow us
>    to isolate these issues from GCC 14 issues that typically occur
>    during the upcoming mass rebuild. 
Is there an RPM of GCC 14 / GCC 13 + these backports anywhere?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Florian Weimer]

* Richard W. M. Jones:

>  On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
> > * Integrate a backport of the GCC 14 changes into the rawhide GCC 13
> >   version (rawhide only, not Fedora 39 or 38).  This will allow us
> >   to isolate these issues from GCC 14 issues that typically occur
> >   during the upcoming mass rebuild.
>
>  Is there an RPM of GCC 14 / GCC 13 + these backports anywhere? 
Jakub did a scratch build recently:

  gcc-14.0.0-0.2.fc40
  <https://koji.fedoraproject.org/koji/taskinfo?taskID=109799520>

Note that this is a development compiler.

For tracking down compatibility issues, you can also use mock with the
instrumented compiler repository:

 
<https://fedoraproject.org/wiki/Toolchain/PortingToModernC#Special_COPR_re...

This is based on GCC 13, so fewer moving parts.

Thanks,
Florian

[Richard W.M. Jones]

On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
>  nbdkit               rjones 
Can you help me to understand the build error in this log?

https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdki...

I'm not exactly sure what / where the error is supposed to be.

Possibly it is complaining about this autoconf test, but I don't
understand what's wrong with the cast, since AFAIK making a pointer
"more const" should be fine:

  configure:20816: checking if environ is declared in header files
  configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Werror=implicit-function-declaration -Werror=implicit-int
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
  conftest.c: In function 'test':
  conftest.c:62:22: error: initialization of 'const char **' from incompatible
pointer type 'char **'
     62 |   const char **env = environ;
        |                      ^~~~~~~

(source:
https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248...)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Florian Weimer]

* Richard W. M. Jones:

>  On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
> > nbdkit               rjones
>
>  Can you help me to understand the build error in this log?
>
>
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdki...
>
>  I'm not exactly sure what / where the error is supposed to be.
>
>  Possibly it is complaining about this autoconf test, but I don't
>  understand what's wrong with the cast, since AFAIK making a pointer
>  "more const" should be fine:
>
>    configure:20816: checking if environ is declared in header files
>    configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
>    conftest.c: In function 'test':
>    conftest.c:62:22: error: initialization of 'const char **' from incompatible
> pointer type 'char **'
>       62 |   const char **env = environ;
>          |                      ^~~~~~~
>
>  (source:
> https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248...)
The inner pointer is const, not the outer pointer.  The rule about
compatibility only applies to the outer const, not to any inner const.

Thanks,
Florian

[Richard W.M. Jones]

On Sat, Dec 02, 2023 at 09:15:28PM +0000, Richard W.M. Jones wrote:
>  On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
>  > nbdkit               rjones
>  
>  Can you help me to understand the build error in this log?
>  
>
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdki...
>  
>  I'm not exactly sure what / where the error is supposed to be.
>  
>  Possibly it is complaining about this autoconf test, but I don't
>  understand what's wrong with the cast, since AFAIK making a pointer
>  "more const" should be fine:
>  
>    configure:20816: checking if environ is declared in header files
>    configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
>    conftest.c: In function 'test':
>    conftest.c:62:22: error: initialization of 'const char **' from incompatible
> pointer type 'char **'
>       62 |   const char **env = environ;
>          |                      ^~~~~~~
>  
>  (source:
> https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248...)
Fixed upstream here:
https://gitlab.com/nbdkit/nbdkit/-/commit/32a9ee6650654469cd591a3ae26842c...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit

[Florian Weimer]

* Richard W. M. Jones:

>  On Sat, Dec 02, 2023 at 09:15:28PM +0000, Richard W.M. Jones wrote:
> > On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
> > > nbdkit               rjones
> > 
> > Can you help me to understand the build error in this log?
> > 
> >
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdki...
> > 
> > I'm not exactly sure what / where the error is supposed to be.
> > 
> > Possibly it is complaining about this autoconf test, but I don't
> > understand what's wrong with the cast, since AFAIK making a pointer
> > "more const" should be fine:
> > 
> >   configure:20816: checking if environ is declared in header files
> >   configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
> >   conftest.c: In function 'test':
> >   conftest.c:62:22: error: initialization of 'const char **' from
> incompatible pointer type 'char **'
> >      62 |   const char **env = environ;
> >         |                      ^~~~~~~
> > 
> > (source:
> https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248...)
>
>  Fixed upstream here:
>  https://gitlab.com/nbdkit/nbdkit/-/commit/32a9ee6650654469cd591a3ae26842c...
Thanks.  Could you bring this into rawhide as well?

Florian

[Richard W.M. Jones]

On Mon, Dec 04, 2023 at 02:28:03PM +0100, Florian Weimer wrote:
>  * Richard W. M. Jones:
>  
>  > On Sat, Dec 02, 2023 at 09:15:28PM +0000, Richard W.M. Jones wrote:
>  >> On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
>  >> > nbdkit               rjones
>  >> 
>  >> Can you help me to understand the build error in this log?
>  >> 
>  >>
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdki...
>  >> 
>  >> I'm not exactly sure what / where the error is supposed to be.
>  >> 
>  >> Possibly it is complaining about this autoconf test, but I don't
>  >> understand what's wrong with the cast, since AFAIK making a pointer
>  >> "more const" should be fine:
>  >> 
>  >>   configure:20816: checking if environ is declared in header files
>  >>   configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Werror=implicit-function-declaration -Werror=implicit-int
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
>  >>   conftest.c: In function 'test':
>  >>   conftest.c:62:22: error: initialization of 'const char **' from
> incompatible pointer type 'char **'
>  >>      62 |   const char **env = environ;
>  >>         |                      ^~~~~~~
>  >> 
>  >> (source:
> https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248...)
>  >
>  > Fixed upstream here:
>  > https://gitlab.com/nbdkit/nbdkit/-/commit/32a9ee6650654469cd591a3ae26842c...
>  
>  Thanks.  Could you bring this into rawhide as well? 
Building right now ...

https://koji.fedoraproject.org/koji/taskinfo?taskID=109893172

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Kevin Kofler]

Florian Weimer wrote:
>  The final patches for GCC 14 are currently under upstream review and
>  should land very soon.  Earlier, I had received feedback that the larger
>  community desires just one transition, so we end up with the following
>  warnings which turn into errors by default:
>  
>    -Wimplicit-function-declaration
>    -Wimplicit-int
>    -Wint-conversion
>    -Wreturn-mismatch (new, previously part of -Wreturn-types)
>    -Wdeclaration-missing-parameter-type (new, previously unnamed)
>    -Wincompatible-pointer-types
>  
>  Only the first two were covered in the initial Fedora conversion work. 
As much as I understand the point of -Werror=implicit-function-declaration 
(since implicit function declarations can cause several subtle bugs), and 
implicit int is obscure enough for its removal to not be a big problem (even 
though its potential for causing bugs is much lower), as much I have to 
wonder about the others. Especially the incompatible pointer types sound 
more like nitpicking than actual bugs (though I guess strict aliasing can 
cause issues with those, but then I would expect to see -Wstrict-aliasing 
warnings).

        Kevin Kofler

[Jakub Jelinek]

On Tue, Dec 05, 2023 at 04:38:55AM +0100, Kevin Kofler via devel wrote:
>  Florian Weimer wrote:
>  > The final patches for GCC 14 are currently under upstream review and
>  > should land very soon.  Earlier, I had received feedback that the larger
>  > community desires just one transition, so we end up with the following
>  > warnings which turn into errors by default:
>  > 
>  >   -Wimplicit-function-declaration
>  >   -Wimplicit-int
>  >   -Wint-conversion
>  >   -Wreturn-mismatch (new, previously part of -Wreturn-types)
>  >   -Wdeclaration-missing-parameter-type (new, previously unnamed)
>  >   -Wincompatible-pointer-types
>  > 
>  > Only the first two were covered in the initial Fedora conversion work.
>  
>  As much as I understand the point of -Werror=implicit-function-declaration 
>  (since implicit function declarations can cause several subtle bugs), and 
>  implicit int is obscure enough for its removal to not be a big problem (even 
>  though its potential for causing bugs is much lower), as much I have to 
>  wonder about the others. Especially the incompatible pointer types sound 
>  more like nitpicking than actual bugs (though I guess strict aliasing can 
>  cause issues with those, but then I would expect to see -Wstrict-aliasing 
>  warnings). 
Look at the gimp case, where a function prototype was expecting double *
argument but caller was calling it with address of float.
void foo (double *);
void
bar ()
{
  float f = 5.0f;
  foo (&f);
}
While this resulted in a warning even without -Wall, clearly nobody noticed
until this was made an error:
file-tiff-load.c:1372:56: warning: passing argument 2 of ‘gimp_image_get_resolution’ from
incompatible pointer type [-Wincompatible-pointer-types]
 1372 |                     gimp_image_get_resolution (*image, &xres, &yres);
      |                                                        ^~~~~
      |                                                        |
      |                                                        gfloat * {aka float *}
In file included from ../../libgimp/gimp_pdb_headers.h:55,
                 from ../../libgimp/gimp.h:66,
                 from file-tiff-load.c:52:
../../libgimp/gimpimage_pdb.h:179:86: note: expected ‘gdouble *’ {aka ‘double *’} but
argument is of type ‘gfloat *’ {aka ‘float *’}
  179 |                                                                 gdouble           
 *xresolution,
      |                                                                
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
file-tiff-load.c:1372:63: warning: passing argument 3 of ‘gimp_image_get_resolution’ from
incompatible pointer type [-Wincompatible-pointer-types]
 1372 |                     gimp_image_get_resolution (*image, &xres, &yres);
      |                                                               ^~~~~
      |                                                               |
      |                                                               gfloat * {aka float
*}
../../libgimp/gimpimage_pdb.h:180:86: note: expected ‘gdouble *’ {aka ‘double *’} but
argument is of type ‘gfloat *’ {aka ‘float *’}
  180 |                                                                 gdouble           
 *yresolution);
      |                                                                
~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~

	Jakub

[Florian Weimer]

* Jakub Jelinek:

>  On Tue, Dec 05, 2023 at 04:38:55AM +0100, Kevin Kofler via devel
> wrote:
> > Florian Weimer wrote:
> > > The final patches for GCC 14 are currently under upstream review and
> > > should land very soon.  Earlier, I had received feedback that the larger
> > > community desires just one transition, so we end up with the following
> > > warnings which turn into errors by default:
> > > 
> > >   -Wimplicit-function-declaration
> > >   -Wimplicit-int
> > >   -Wint-conversion
> > >   -Wreturn-mismatch (new, previously part of -Wreturn-types)
> > >   -Wdeclaration-missing-parameter-type (new, previously unnamed)
> > >   -Wincompatible-pointer-types
> > > 
> > > Only the first two were covered in the initial Fedora conversion work.
> > 
> > As much as I understand the point of -Werror=implicit-function-declaration 
> > (since implicit function declarations can cause several subtle bugs), and 
> > implicit int is obscure enough for its removal to not be a big problem (even 
> > though its potential for causing bugs is much lower), as much I have to 
> > wonder about the others. Especially the incompatible pointer types sound 
> > more like nitpicking than actual bugs (though I guess strict aliasing can 
> > cause issues with those, but then I would expect to see -Wstrict-aliasing 
> > warnings).
>
>  Look at the gimp case, where a function prototype was expecting double *
>  argument but caller was calling it with address of float.
>  void foo (double *);
>  void
>  bar ()
>  {
>    float f = 5.0f;
>    foo (&f);
>  } 
>  While this resulted in a warning even without -Wall, clearly nobody
> noticed
>  until this was made an error: 
And this results in an out-of-bounds write and potential memory
corruption.

That's actually not uncommon for such bugs.  Here's a similar issue for
python-tables:

 
<https://github.com/PyTables/PyTables/commit/44168c0d8e4c059ea51c8bc98a107...

Although the critical type size mismatch happens on 32-bit architectures
and Windows only.  Problems like these are the reason why I don't think
the Clang approach of restricting to incompatible-function-pointer-types
only makes much sense.

Thanks,
Florian

[Kevin Kofler]

Florian Weimer wrote:
>  Although the critical type size mismatch happens on 32-bit
> architectures
>  and Windows only.  Problems like these are the reason why I don't think
>  the Clang approach of restricting to incompatible-function-pointer-types
>  only makes much sense. 
Uhm, yeah, there are certainly cases where the complaint about mismatched 
pointer types is valid. But last I checked, the warning that is now being 
turned into an error also complained about "mismatches" where the types are 
actually exactly the same on the given architecture, such as int vs. long on 
32-bit (or 64-bit Windows), or long vs. long long on 64-bit LP64. And those 
"mismatches" can easily happen without being an actual issue, because, e.g., 
the program uses its own definition equivalent to something like size_t or 
ptrint_t (especially the latter, since it is non-C90 and hence considered 
non-standard by the large pool of software still targeting C90 only, but I 
have also seen a lot of custom size_t/ssize_t reinventions) and passes a 
pointer to that where a size_t * or ptrint_t * or such is expected. 

E.g., I have seen Java bindings doing something like:
jlong foo;
#if SIZEOF_SIZE_T == 8
  function_that_expects_an_ssize_t_pointer(&foo);
#else
  ssize_t temp = (ssize_t) foo;
  function_that_expects_an_ssize_t_pointer(&temp);
  foo = (jlong) temp;
#endif

Of course, the compiler has no way to know whether the code is doing 
something like this or just incorrectly assuming that 
sizeof(ssize_t)==sizeof(jlong) (i.e., 8) everywhere.

        Kevin Kofler