On 4/27/21 3:58 PM, Joseph Myers wrote:
> On Tue, 27 Apr 2021, Martin Sebor via Libc-alpha wrote:
> 
>> These are warnings in my build (I've seen a few others scroll by
>> and have always assumed they were expected(*)).  Those you pasted
> 
> Most warnings are errors by default (unless you use --disable-werror,
> which should never normally be used in glibc development unless you're
> e.g. reviewing the warnings you get if you add extra warning options to
> those with which glibc is built by default, in order to fix those warnings
> before adding the extra options).

Ah, that's what my build script does and I keep forgetting to
change that when working on Glibc (as opposed to testing new
GCC warnings).  My bad.  The attached diff patches up the tests
to pass the function a valid argument.  I'll plan to commit it
shortly unless you prefer some other solution.

Martin

> 
>> I test by simply running make check.  I can make the change to
>> the test if you expect warning-free test builds.
> 
> We expect builds, for all glibc ABIs, free from compile errors or failures
> of tests that can run without needing to execute any code for the glibc
> architecture.  That means no warnings that are turned into errors by
> -Werror.  There are some warnings for which -Wno-error or pragmas are used
> to stop them being errors; all other warnings are disallowed.
> 
>> [*] Here's an example of a warning I just noticed while rerunning
>> make check:
>>
>> tst-chk1.c: In function ‘do_test’:
> 
> That's an example covered by -Wno-error.
> 
> # We know these tests have problems with format strings, this is what
> # we are testing.  Disable that warning.  They are also testing
> # deprecated functions (notably gets) so disable that warning as well.
> # And they also generate warnings from warning attributes, which
> # cannot be disabled via pragmas, so require -Wno-error to be used.
> CFLAGS-tst-chk1.c += -Wno-format -Wno-deprecated-declarations -Wno-error
> 
> (Any code disabling any warnings or disabling -Werror for them is expected
> to have a comment explaining why it's OK to do so in that case.)
>