Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Zack Weinberg]

On Wed, Dec 13, 2023, at 9:29 AM, Florian Weimer wrote:
>   configure.ac: Define _DEFAULT_SOURCE along with _XOPEN_SOURCE
>   

Trunk autoconf produces a configure script for that library which reports
"checking for getpagesize...yes" and "checking for working mmap... yes",
without the changes in that pull request, with GCC 13 and glibc 2.37,
even if CC is set to

gcc -std=c11 -Werror=implicit-function-declaration -Werror=implicit-int
-Werror=int-conversion -Werror=incompatible-pointer-types

"make check" runs to completion, with no test failures reported.

On the same system, this test program fails to compile with
those options:

#define _XOPEN_SOURCE 600
#include 
int main(void)
{ return getpagesize(); }

complaining about an implicit declaration of getpagesize.

... There may still be a problem, though: after the above tests,
htslib's config.h has "#define HAVE_GETPAGESIZE 1" in it, because
AC_FUNC_MMAP provided its own declaration of getpagesize.  There
may be programs that trust HAVE_GETPAGESIZE to mean unistd.h declares
getpagesize.

> I can't test this with htslib unfortunately because I'm not able to
> build autoconf from sources for some reason.

What errors are you getting?

zw

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Sam James]

Florian Weimer  writes:

> * Zack Weinberg:
>
>> Paul Eggert made some changes back in May that attempt to address this:
>> commits 028526149ee804617a302ccef22cc6adbda681b0 and
>> 33c26d2700f927432c756ccf7a4fc89403d35b95.  Do you have a minimized
>> test case for the problem (both the original problem and any remaining
>> issues you're aware of are useful to me)?
>
> The latest installment of this issue is here:
>
>   configure.ac: Define _DEFAULT_SOURCE along with _XOPEN_SOURCE
>   
>
> I wasn't aware of this change from
> 33c26d2700f927432c756ccf7a4fc89403d35b95 ("Fix port of AC_FUNC_MMAP"),
> or maybe I just forgot about it:
>
> +#ifndef getpagesize
> +# ifdef _SC_PAGESIZE
> +#  define getpagesize() sysconf (_SC_PAGESIZE)
> +# elif defined _SC_PAGE_SIZE
> +#  define getpagesize() sysconf (_SC_PAGE_SIZE)
> +# elif HAVE_GETPAGESIZE
> +int getpagesize ();
> +# else
>
> This should indeed isolate this test from the outcome of the getpagesize
> check because it now prefers sysconf.

Thanks for raising this one - Zack had asked me for any outstanding
issues and I had something like this in the back of my head but couldn't
yet find a good summary.

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Paul Eggert]

On 2023-12-12 01:32, Arsen Arsenović wrote:


Paul Eggert  writes:

Although it'll be helpful for Autoconf to work by default with those two
options, it's not essential because it's bad advice for builders to *configure*
with all the options suggested in "Compiler Options Hardening Guide for C and
C++"[1]. The advice should merely be to *build* with those options.


These options tell compilers to work as the C standard requires.  They
will soon not be flags that need to be added explicitly.  See:
https://inbox.sourceware.org/87ttp3tek1@oldenburg.str.redhat.com/


Thanks for the heads-up; I wasn't aware of that effort. However, the 
behavior it's proposing (defaulting to errors for -Wint-conversion, 
Wreturn-mismatch, -Wdeclaration-missing-parameter-type, 
-Wincompatible-pointer-types) shouldn't be much of a problem for 
Autoconf. These warnings are less intrusive and controversial than the 
warning options suggested in [1] and I don't think they'll be much of a 
problem for Autoconf or for Autoconf-using programs.




This is because the recommended options include controversial ones like
-Wconversion that can be harmful in C code. The only way to pacify -Wconversion
is to complicate the code by inserting casts that can lower code safety and
quality. Even Gnulib, which goes far beyond [1] in recommending warning
options, disables -Wconversion.


I'm not sure I agree that handling real lossy conversions lowers code
quality, but this flag is not a behavior required by the standard, so I
suppose not assuming it is OK.


Yes, although -Wconversion can sometimes be useful unfortunately it too 
often forces you to put in casts that can mask serious problems later. 
The C standard doesn't require -Wconversion diagnostics and I expect it 
never will.


[1]: 
https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++ 

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Frederic Berat]

On Wed, Dec 13, 2023 at 3:30 PM Florian Weimer  wrote:

> * Zack Weinberg:
>
> > Paul Eggert made some changes back in May that attempt to address this:
> > commits 028526149ee804617a302ccef22cc6adbda681b0 and
> > 33c26d2700f927432c756ccf7a4fc89403d35b95.  Do you have a minimized
> > test case for the problem (both the original problem and any remaining
> > issues you're aware of are useful to me)?
>
> The latest installment of this issue is here:
>
>   configure.ac: Define _DEFAULT_SOURCE along with _XOPEN_SOURCE
>   
>
> I wasn't aware of this change from
> 33c26d2700f927432c756ccf7a4fc89403d35b95 ("Fix port of AC_FUNC_MMAP"),
> or maybe I just forgot about it:
>
> +#ifndef getpagesize
> +# ifdef _SC_PAGESIZE
> +#  define getpagesize() sysconf (_SC_PAGESIZE)
> +# elif defined _SC_PAGE_SIZE
> +#  define getpagesize() sysconf (_SC_PAGE_SIZE)
> +# elif HAVE_GETPAGESIZE
> +int getpagesize ();
> +# else
>
> This should indeed isolate this test from the outcome of the getpagesize
> check because it now prefers sysconf.
>
> I can't test this with htslib unfortunately because I'm not able to
> build autoconf from sources for some reason.
>

You can use the SRPM available here, that's plain autoconf 2.72d:
https://copr.fedorainfracloud.org/coprs/fberat/autoconf.2.72d-1/build/6710467/


> Thanks,
> Florian
>
>
>

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Florian Weimer]

* Zack Weinberg:

> Paul Eggert made some changes back in May that attempt to address this:
> commits 028526149ee804617a302ccef22cc6adbda681b0 and
> 33c26d2700f927432c756ccf7a4fc89403d35b95.  Do you have a minimized
> test case for the problem (both the original problem and any remaining
> issues you're aware of are useful to me)?

The latest installment of this issue is here:

  configure.ac: Define _DEFAULT_SOURCE along with _XOPEN_SOURCE
  

I wasn't aware of this change from
33c26d2700f927432c756ccf7a4fc89403d35b95 ("Fix port of AC_FUNC_MMAP"),
or maybe I just forgot about it:

+#ifndef getpagesize
+# ifdef _SC_PAGESIZE
+#  define getpagesize() sysconf (_SC_PAGESIZE)
+# elif defined _SC_PAGE_SIZE
+#  define getpagesize() sysconf (_SC_PAGE_SIZE)
+# elif HAVE_GETPAGESIZE
+int getpagesize ();
+# else

This should indeed isolate this test from the outcome of the getpagesize
check because it now prefers sysconf.

I can't test this with htslib unfortunately because I'm not able to
build autoconf from sources for some reason.

Thanks,
Florian

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Zack Weinberg]

On Wed, Dec 13, 2023, at 4:27 AM, Florian Weimer wrote:
> I'm not aware of any generic issues in current-ish autoconf.  Some
> macros needed fixing, but not the basic ones modified by those two
> commits.  Even autoconf 2.69 is mostly fine—you have to go back much
> farther to find versions with generic issues.

Good to hear.  I'd be testing these things myself but I've gotten so
confused about which changes are actually in which released versions of
which compilers that I wouldn't have any confidence in anything I did.

> Some concern has been expressed that the AC_FUNC_MMAP test fails
> incorrectly if getpagesize is detected, but does not have a
> prototype in .  One way this can happen is if a project
> does not use AC_USE_SYSTEM_EXTENSIONS, but says (with glibc)
> _XOPEN_SOURCE directly, but not _DEFAULT_SOURCE.  Reportedly, it
> also happens on Darwin.  I think the autoconf position is that these
> projects should use AC_USE_SYSTEM_EXTENSIONS instead, so no attempt
> has been made to fix it.

Paul Eggert made some changes back in May that attempt to address this:
commits 028526149ee804617a302ccef22cc6adbda681b0 and
33c26d2700f927432c756ccf7a4fc89403d35b95.  Do you have a minimized
test case for the problem (both the original problem and any remaining
issues you're aware of are useful to me)?

zw

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Florian Weimer]

* Michael Orlitzky:

> On Mon, 2023-12-11 at 10:55 -0500, David A. Wheeler wrote:
>> All:
>> 
>> Will the latest version of autoconf work by default when the compiler has 
>> these options enabled?:
>> -Werror=implicit-int
>> -Werror=implicit-function-declaration
>> 
>
> I think the two fixes we're waiting for in the next release are,
>
>   * https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=8b5e2016
>   * https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bf5a7595
>
> And then all we need... is for every project on earth to autoreconf.
> The real problem though is the thousands of existing configure.ac files
> with their own buggy compile/link tests that will silently fail.
>
> Here's a short TODO list: https://bugs.gentoo.org/870412

Just to reiterate, these autoconf commits are not related to David's
initial question or the warnings listed in the summary of the Gentoo bug
(which currently are implicit-function-declaration, implicit-int,
int-conversion, incompatible-pointer-types).  I'm not aware of any
generic issues in current-ish autoconf.  Some macros needed fixing, but
not the basic ones modified by those two commits.  Even autoconf 2.69 is
mostly fine—you have to go back much farther to find versions with
generic issues.

Some concern has been expressed that the AC_FUNC_MMAP test fails
incorrectly if getpagesize is detected, but does not have a prototype in
.  One way this can happen is if a project does not use
AC_USE_SYSTEM_EXTENSIONS, but says (with glibc) _XOPEN_SOURCE directly,
but not _DEFAULT_SOURCE.  Reportedly, it also happens on Darwin.  I
think the autoconf position is that these projects should use
AC_USE_SYSTEM_EXTENSIONS instead, so no attempt has been made to fix it.

Thanks,
Florian

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Arsen Arsenović]

Hi Paul,

Paul Eggert  writes:

> On 12/11/23 07:55, David A. Wheeler wrote:
>> Will the latest version of autoconf work by default when the compiler has
>> these options enabled?:
>> -Werror=implicit-int
>> -Werror=implicit-function-declaration
>
> Although it'll be helpful for Autoconf to work by default with those two
> options, it's not essential because it's bad advice for builders to 
> *configure*
> with all the options suggested in "Compiler Options Hardening Guide for C and
> C++"[1]. The advice should merely be to *build* with those options.

These options tell compilers to work as the C standard requires.  They
will soon not be flags that need to be added explicitly.  See:
https://inbox.sourceware.org/87ttp3tek1@oldenburg.str.redhat.com/

The lack of these flags by default has been a great deterioration in the
quality of the C language as well as the ability to teach beginner
programmers C.  The fact that our compilers permitted this purely
undesirable behavior in spite of the standard, or even basic sanity, is
a shame.

> This is because the recommended options include controversial ones like
> -Wconversion that can be harmful in C code. The only way to pacify 
> -Wconversion
> is to complicate the code by inserting casts that can lower code safety and
> quality. Even Gnulib, which goes far beyond [1] in recommending warning
> options, disables -Wconversion.

I'm not sure I agree that handling real lossy conversions lowers code
quality, but this flag is not a behavior required by the standard, so I
suppose not assuming it is OK.

> For controversial options like -Wconversion we shouldn't expect 'configure'
> scripts to pacify compilers in all cases. And since we shouldn't expect that,
> we shouldn't recommend builders to use all the options in [1] when 
> configuring.
>
> [1]:
> https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++

Thanks, have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Paul Eggert]

On 12/11/23 08:24, Michael Orlitzky wrote:

I think the two fixes we're waiting for in the next release are,

   *https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=8b5e2016
   *https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bf5a7595


The first commit is about -Wold-style-definition, a different matter.

-Wold-style-definition is tricky because it can diagnose code like this:

  int f () { return 2; }

This is old-style in C89 through C17 but is *not* old-style in C2x. 
Current 'gcc -std=c2x -Wold-style-definition' does not warn about it, 
even though 'gcc -std=c17 -Wold-style-definition' does warn.


As far as I know, the next Autoconf release should work with 
-Wold-style-definition, regardless of whether you're using C2x or an 
earlier C, so long as the earlier C is not so old that the compiler 
lacks -Wold-style-definition or equivalent (and yes, we still have some 
code for those ancient systems!).


However, this is even less important than working with -Wimplicit-int 
and -Wimplicit-function-declaration.




The real problem though is the thousands of existing configure.ac files
with their own buggy compile/link tests that will silently fail.


Quite true. It'd be unwise to configure a package with 
'-Werror=implicit-int' or -Werror=implicit-function-declaration' without 
a very careful look at all the configure.ac and .m4 and etc. files in 
that package.

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Paul Eggert]

On 12/11/23 07:55, David A. Wheeler wrote:

Will the latest version of autoconf work by default when the compiler has these 
options enabled?:
-Werror=implicit-int
-Werror=implicit-function-declaration


Although it'll be helpful for Autoconf to work by default with those two 
options, it's not essential because it's bad advice for builders to 
*configure* with all the options suggested in "Compiler Options 
Hardening Guide for C and C++"[1]. The advice should merely be to 
*build* with those options.


This is because the recommended options include controversial ones like 
-Wconversion that can be harmful in C code. The only way to pacify 
-Wconversion is to complicate the code by inserting casts that can lower 
code safety and quality. Even Gnulib, which goes far beyond [1] in 
recommending warning options, disables -Wconversion.


For controversial options like -Wconversion we shouldn't expect 
'configure' scripts to pacify compilers in all cases. And since we 
shouldn't expect that, we shouldn't recommend builders to use all the 
options in [1] when configuring.



[1]: 
https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Zack Weinberg]

On Mon, Dec 11, 2023, at 11:24 AM, Michael Orlitzky wrote:
> On Mon, 2023-12-11 at 10:55 -0500, David A. Wheeler wrote:
>> Will the latest version of autoconf work by default when the compiler
>> has these options enabled?:
>>-Werror=implicit-int
>>-Werror=implicit-function-declaration
>
> I think the two fixes we're waiting for in the next release are,
>
>   * https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=8b5e2016
>   * https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bf5a7595

For clarity, both of these commits were already included in the 2.72d beta 
release:
.
If you are able, please test 2.72d with a compiler that has -Werror=implicit-int
and/or -Werror=implicit-function-declaration enabled by default, and report
your findings here as soon as possible.

I will consider any failure in autoconf's own testsuite, caused by
-Werror=implicit-int and/or -Werror=implicit-function-declaration,
to be a release blocker, unless it proves to be the fault of the system's
C library (e.g. some header file is _supposed_ to provide a prototype for
some function but it doesn't).  Regressions from the above two commits
will also be considered blockers, except if they boil down to "configure
scripts can't be used with a K&R compiler anymore", which is unavoidable.

> And then all we need... is for every project on earth to autoreconf.
> The real problem though is the thousands of existing configure.ac
> files with their own buggy compile/link tests that will silently fail.
>
> Here's a short TODO list: https://bugs.gentoo.org/870412

If there's anything we can do from our end to make that list easier to
grind through, please let us know.

zw

Re: Will autoconf work with -Werror=implicit-int and -Werror=implicit-function-declaration ?

[Michael Orlitzky]

On Mon, 2023-12-11 at 10:55 -0500, David A. Wheeler wrote:
> All:
> 
> Will the latest version of autoconf work by default when the compiler has 
> these options enabled?:
> -Werror=implicit-int
> -Werror=implicit-function-declaration
> 

I think the two fixes we're waiting for in the next release are,

  * https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=8b5e2016
  * https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bf5a7595

And then all we need... is for every project on earth to autoreconf.
The real problem though is the thousands of existing configure.ac files
with their own buggy compile/link tests that will silently fail.

Here's a short TODO list: https://bugs.gentoo.org/870412