With gcc 14 around the corner, we really need to fix at least some compiler warnings

[ndim]

BTW looks lile with latest glibc and gcc 14.x test suite build fails because it cannot be build wit -D_FORTIFY_SOURCE=3 which turns -Wimplicit-int and -Wimplicit-function-declaration into errors

/usr/bin/g++ -DHAVE_CONFIG_H -I. -I..  -I../libgphoto2_port -I..  -std=c++98 -pedantic -Wall -Wextra -Werror  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -grecord-gcc-switches -pipe -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fdata-sections -ffunction-sections -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -flto=auto -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Werror=format-security -c -o test_pedantic_cxx98-test-pedantic-compilation.o `test -f 'test-pedantic-compilation.cxx' || echo './'`test-pedantic-compilation.cxx
test-pedantic-compilation.cxx: error: -Wno-implicit-int detected - is this intentional ? [-Werror]
test-pedantic-compilation.cxx: error: -Wno-implicit-function-declaration detected - is this intentional ? [-Werror]
cc1plus: all warnings being treated as errors
make[2]: *** [Makefile:1308: test_pedantic_cxx98-test-pedantic-compilation.o] Error 1

Originally posted by @kloczek in #773 (comment)

[ndim]

gcc 14 is coming, and will enable some warnings as errors by default.

The mass rebuilds for the upcoming Fedora 40 have exposed some of that already, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2261324 or https://koji.fedoraproject.org/koji/taskinfo?taskID=112078167 (https://kojipkgs.fedoraproject.org//work/tasks/8282/112078282/build.log).

We need a systematic effort to eliminate compiler warnings, both relatively quickly to keep libgphoto2 building with gcc 14, and then more completely for our own sanity and peace of mind.

Ideally, we will eventually build with zero warnings, but that will take a lot of effort.

I recently tried looking into some integer warnings, but we have a lot of them and many are systematic issues, not just the occasional forgotten cast from ssize_t to size_t having ruled out the < 0 case.

Things like comparing int members in one PTP related struct with unsigned int members of the same name in a different struct with the same member names. No idea what the PTP specs actually says about the signedness of those values, but what I could find with those struct member names in some PTP standard documents was partially 4 byte and partially 2 byte values, both of which are represented by int and unsigned int in our codebase.

Anyway, such things should be solvable by properly using uint16_t and uint32_t where applicable. I would hope this is only libgphoto2/libgphoto2_port internal stuff and does not affect the external APIs.

[msmeissn]

currently openSUSE tumbleweed does not have gcc14 yet, so I can take it up once it gets it.

[ndim]

I have set up a VM with Fedora 40 for a quick check, but I could not reproduce the original post.

I want to merge the two configure scripts into one first, and only then start fixing the warnings. That should save on build times.

[kloczek]

Actually reported issue is result of use latest devel glibc with -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 in CFLAGS which changes those warnings into errors.

Instead wasting time on create Fedora build env better would be just sort out those warnings.

[ndim]

Not sure why trying to reproduce a reported problem would a waste of time...

Anyway, I could not reproduce the issue using the Fedora 40 packages

gcc-14.0.1-0.4.fc40.x86_64
glibc-2.38.9000-39.fc40.x86_64

running

autoreconf -vis .
./configure --with-camlibs=everything
make -j$(nproc) CFLAGS="-O2 -g -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3" CXXFLAGS="-O2 -g -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3" all check

on libgphoto2 commit 846ae9f.

What exactly is "[the] latest devel glibc"? What libgphoto2 commit are you building? Using what commands?

[kloczek]

What exactly is "[the] latest devel glibc"? What libgphoto2 commit are you building? Using what commands?

Snapshot of the glibc which is now used in fedora rawhide.

[ndim]

Another thing, this time building for i686. Quoting https://src.fedoraproject.org/rpms/libgphoto2/pull-request/5:

ptp2/chdk.c:1186:41: error: passing argument 3 of 'jpeg_mem_dest' from incompatible pointer type [-Wincompatible-pointer-types]
/usr/include/jpeglib.h:922:43: note: expected 'long unsigned int *' but argument is of type 'uint64_t *' {aka 'long long unsigned int *'}

[yselkowitz]

Another thing, this time building for i686. Quoting https://src.fedoraproject.org/rpms/libgphoto2/pull-request/5:

ptp2/chdk.c:1186:41: error: passing argument 3 of 'jpeg_mem_dest' from incompatible pointer type [-Wincompatible-pointer-types]
/usr/include/jpeglib.h:922:43: note: expected 'long unsigned int *' but argument is of type 'uint64_t *' {aka 'long long unsigned int *'}

This is already fixed; see #941

[msmeissn]

its not the -D_FORTIFY_SOURCE=3 usually turning on errors, but try

-fhardened or so which is new with gcc14

[fweimer-rh]

This:

test-pedantic-compilation.cxx: error: -Wno-implicit-int detected - is this intentional ? [-Werror]
test-pedantic-compilation.cxx: error: -Wno-implicit-function-declaration detected - is this intentional ? [-Werror]

is a downstream-only thing in Fedora, related to its use of annobin. If this reproduces in Fedora rawhide, it should be raised as an annobin bug.

[kloczek]

its not the -D_FORTIFY_SOURCE=3 usually turning on errors, but try

-fhardened or so which is new with gcc14

I'm not using such option.

[kloczek]

is a downstream-only thing in Fedora, related to its use of annobin. If this reproduces in Fedora rawhide, it should be raised as an annobin bug.

Why not tolerating some exact warning is kind of bug? 🤔