On 2023-09-04 18:04, Bruno Haible wrote:
It's still a bit early to do so, because it can trigger compilation errors
when people are not super careful
Doesn't Gnulib's nullptr module fix the problems, whatever they are?
(The URL you gave needs a GitHub login to view, which is a bit unfriendly.)
I did:
> 2023-09-04 Bruno Haible
>
> string-buffer tests: Fix a gcc -Wformat warning.
> * tests/test-string-buffer.c: Don't assume that wint_t has the same size
> as 'int'.
Oops, that doesn't even compile. Fix:
2023-09-04 Bruno Haible
string-buffer tests: Fix a
These two warnings
unistr/test-u-strtok.h:54:28: warning: allocated buffer size is not a multiple
of the pointee's size [CWE-131] [-Wanalyzer-allocation-size]
unistr/test-u-strtok.h:56:28: warning: allocated buffer size is not a multiple
of the pointee's size [CWE-131] [-Wanalyzer-allocation-siz
Paul Eggert wrote:
> I've been gradually switching code to use nullptr instead of NULL, so
> that GNU code won't be stuck in the 2010s.
It's still a bit early to do so, because it can trigger compilation errors
when people are not super careful (just saw this one today: [1]). It has
hurt me also
On 2023-09-04 15:44, Bruno Haible wrote:
- fs = 0;
+ fs = NULL;
This use of 0 probably dates back to when the GNU Coding Standards said,
in effect "Don't bother changing 0 to NULL when it doesn't affect
semantics."
I've been gradually switching code to use nullptr instead
This warning can be fixed like the one in test-raise.c:
test-sigpipe.c:34:3: warning: call to 'exit' from within signal handler
[CWE-479] [-Wanalyzer-unsafe-call-within-signal-handler]
2023-09-04 Bruno Haible
sigpipe tests: Fix -Wanalyzer-unsafe-call-within-signal-handler warning.
The argp code still uses 0 to denote a null pointer, like in the 1980ies.
It makes the code harder to understand than necessary.
2023-09-04 Bruno Haible
argp: Distinguish NULL and '\0' from 0.
* lib/argp-pin.c: Include .
(program_invocation_short_name, program_invocati
This warning
argp-help.c:645:21: warning: use of uninitialized value '*hol.entries'
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
is justified. Here's a fix.
2023-09-04 Bruno Haible
argp: Fix gcc -Wanalyzer-use-of-uninitialized-value warning.
* lib/argp-help.c (hol_find
This patch fixes the warning
unictype/test-categ_byname.c:209:3: warning: statement with no effect
[-Wunused-value]
2023-09-04 Bruno Haible
unictype/category-byname tests: Fix gcc -Wunused-value warning.
* tests/unictype/test-categ_byname.c (main): Add some tests for categor
This warning exists for a pretty long time as well:
unigbrk/test-uc-grapheme-breaks.c:31:1: warning:
'graphemebreakproperty_to_string' defined but not used [-Wunused-function]
2023-09-04 Bruno Haible
unigbrk/uc-grapheme-breaks tests: Fix gcc -Wunused-function warning.
* test
I've seen these two warnings more than once:
test-bitset.c:277:19: warning: variable 'i' set but not used
[-Wunused-but-set-variable]
test-nonblocking-misc.h:101:10: warning: variable 'spent_time' set but not used
[-Wunused-but-set-variable]
Time to fix them...
2023-09-04 Bruno Haible
Eric Blake wrote:
> We could, however, add use of the __extension__ keyword anywhere we
> use ({...}) in public macros
That's a good suggestion, thanks. Implemented through the patch below.
In fact, use of the __extension__ keyword not only silences the -Wpedantic
warning. It also allows to use t
These warnings in C++ mode
../gllib/malloc.h:615:1: warning: declaration of 'void* memalign(size_t,
size_t)' has a different exception specifier [-Wsystem-headers]
../gllib/stdio.h:860:1: warning: declaration of 'FILE* fdopen(int, const
char*)' has a different exception specifier [-Wsystem-heade
On Sat, Sep 02, 2023 at 07:54:13PM +0200, Bruno Haible wrote:
> The option "-std=gnu2x" is useful; however, the option "-Wpedantic" that you
> have enabled is generally much less useful.
>
> This code in lib/error.h exists for the purpose of providing actually
> useful warnings about the control f
This warning is easy to fix as well:
unistr/test-strchr.h:91:9: warning: declaration of 'i' shadows a previous local
[-Wshadow=local]
2023-09-04 Bruno Haible
unistr/u{8,16,32}-strchr tests: Fix some gcc -Wshadow warnings.
* tests/unistr/test-strchr.h (test_strchr): Reduce of
These warnings are easy to fix as well:
unistr/test-chr.h:96:9: warning: declaration of 'i' shadows a previous local
[-Wshadow=local]
unistr/test-chr.h:111:11: warning: declaration of 'page_boundary' shadows a
previous local [-Wshadow=local]
unistr/test-chr.h:123:22: warning: declaration of 'i'
These two gcc warnings:
test-pipe-filter-gi1.c:88:17: warning: declaration of 'argv' shadows a
parameter [-Wshadow=local]
test-pipe-filter-ii1.c:110:17: warning: declaration of 'argv' shadows a
parameter [-Wshadow=local]
can be fixed in a way that does not decrease maintainability:
2023-09-04
gcc 13 produces this warning:
test-argv-iter.c:97:35: warning: buffer under-read [CWE-127]
[-Wanalyzer-out-of-bounds]
It's not really a buffer under-read. But the test's logic is complicated
enough that it took me two minutes to understand why it's a false positive.
The test can be simplified ac
These gcc warnings are justified:
test-gc-rijndael.c:70:16: warning: declaration of 'i' shadows a previous local
[-Wshadow=compatible-local]
test-gc-rijndael.c:93:16: warning: declaration of 'i' shadows a previous local
[-Wshadow=compatible-local]
test-gc-rijndael.c:147:16: warning: declaration
These gcc warnings are justified:
test-thread_local.c:87:1: warning: '__thread' is not at beginning of
declaration [-Wold-style-declaration]
test-thread_local.c:88:1: warning: '__thread' is not at beginning of
declaration [-Wold-style-declaration]
test-thread_local.c:89:1: warning: '__thread' is
These two warnings
test-ieee754-h.c:39:4: warning: missing initializer for field 'frac_lo' of
'const struct ' [-Wmissing-field-initializers]
test-ieee754-h.c:40:4: warning: missing initializer for field 'frac_lo' of
'const struct ' [-Wmissing-field-initializers]
are probably consequences of cop
On 2023-09-04 03:07, Bruno Haible wrote:
Is that use of -Wextra an experiment, or do you want to use it always?
Oh, it was just an experiment.
I'm asking because some the warnings that it enables are undesired, IMO,
Quite right.
I expect that many of the warnings you found are false alarm
This gcc warning
test-string-buffer.c:104:29: warning: format '%lc' expects argument of type
'wint_t', but argument 3 has type 'int' [-Wformat=]
is justified: in theory, a platform could have a 64-bit wint_t type. Although
I don't know of any current platform that has this.
2023-09-04 Bruno H
This patch fixes a couple of gcc warnings:
test-gc-hmac-md5.c:41:7: warning: initialization discards 'const' qualifier
from pointer target type [-Wdiscarded-qualifiers]
test-gc-hmac-md5.c:43:18: warning: initialization discards 'const' qualifier
from pointer target type [-Wdiscarded-qualifiers]
This gcc warning can be silenced:
In file included from minmax.h:39,
from file-has-acl.c:32:
/usr/include/x86_64-linux-gnu/sys/param.h:102: warning: "MIN" redefined
102 | #define MIN(a,b) (((a)<(b))?(a):(b))
|
In file included from file-has-acl.c:30:
acl-internal.h:56: not
Here's a concrete counter-proposal. I started with the warnings that
GNU gettext's m4/more-warnings.m4 enables for gcc 13:
WARN_CPPFLAGS_GCC13="-fanalyzer -Wall -Warith-conversion -Wcast-align=strict
-Wdate-time -Wdisabled-optimization -Wdouble-promotion -Wduplicated-branches
-Wduplicated-cond -
Paul Eggert wrote:
> + Adjust to these changes, and fix some warnings elicited by
> + -Wall -Wextra that I ran into while testing.
Is that use of -Wextra an experiment, or do you want to use it always?
I'm asking because some the warnings that it enables are undesired, IMO,
while others a
27 matches
Mail list logo
