Emacs release branch warnings with GCC 8

[Paul Eggert]

The emacs-26 branch has some warnings when compiled on Fedora 28, which
is scheduled for release next week; see attached. This is because Fedora
28 uses GCC 8.0.1, and when --enable-gcc-warnings is used (which is the
default in a build from Git), GCC 8 issues some warnings that GCC 7 does
not. I've patched the master to fix this problem in commits
2b9ab8c8fba849da8bf2aa45e65b122bb937a6b3 and
8c3215e7a47e3caaa005bf573765ed63e0739b89, and could backport these
patches (or a subset) to emacs-26 if there's interest.

Only one of the warnings indicates a real bug, one in emacsclient that
could cause undefined behavior. On the other hand, if we don't pacify
GCC 8 now we're likely to get bug reports about the warnings for quite
some time, and it might be less work for everybody involved if we squash
the warnings now.

[Eli Zaretskii]

Date: Mon, 30 Apr 2018 10:12:36 -0700
The emacs-26 branch has some warnings when compiled on Fedora 28, which
is scheduled for release next week; see attached. This is because Fedora
28 uses GCC 8.0.1, and when --enable-gcc-warnings is used (which is the
default in a build from Git), GCC 8 issues some warnings that GCC 7 does
not.

But a release tarball is not built with --enable-gcc-warnings by
default, right?

I've patched the master to fix this problem in commits
2b9ab8c8fba849da8bf2aa45e65b122bb937a6b3 and
8c3215e7a47e3caaa005bf573765ed63e0739b89, and could backport these
patches (or a subset) to emacs-26 if there's interest.

I'm okay with the first one, but I don't understand how the warnings
you've shown are related to the ATTRIBUTE_MALLOC changes in the second
commit. If those are not necessary to shut up warnings, I'd prefer
not to backport those, as the attribute stuff can be a potential
portability problem.

Thanks.

[Paul Eggert]

Post by Eli Zaretskii
But a release tarball is not built with --enable-gcc-warnings by
default, right?

Right. This is about people who build from a release tarball with
--enable-gcc-warnings, and about people who build from Git (the latter
appear to be a growing number....).

Post by Eli Zaretskii

Post by Paul Eggert
I've patched the master to fix this problem in commits
2b9ab8c8fba849da8bf2aa45e65b122bb937a6b3 and
8c3215e7a47e3caaa005bf573765ed63e0739b89, and could backport these
patches (or a subset) to emacs-26 if there's interest.

I'm okay with the first one, but I don't understand how the warnings
you've shown are related to the ATTRIBUTE_MALLOC changes in the second
commit.

The first commit enables -Wsuggest-attribute=malloc, and the
ATTRIBUTE_MALLOC changes in the second commit then pacifies GCC in that
area. We could change the first commit to not enable
-Wsuggest-attribute=malloc and this would simplify the second commit,
though we'd then be differing from Gnulib in the first commit.

[Eli Zaretskii]

Date: Mon, 30 Apr 2018 12:52:59 -0700
The first commit enables -Wsuggest-attribute=malloc, and the
ATTRIBUTE_MALLOC changes in the second commit then pacifies GCC in that
area. We could change the first commit to not enable
-Wsuggest-attribute=malloc and this would simplify the second commit,
though we'd then be differing from Gnulib in the first commit.

I'd prefer to leave -Wsuggest-attribute=malloc out on the release
branch, for now. We could add that after 26.1 is released, hopefully
soon.

Thanks.

[Paul Eggert]

Post by Eli Zaretskii
I'd prefer to leave -Wsuggest-attribute=malloc out on the release
branch, for now.

OK, I installed the attached backport into the emacs-26 branch; it does
the minimum to silence the diagnostics, without adding the new GCC 8
warning options.