GCC 11 has a new '-fanalyzer' implementation [1].
When applied to a gnulib testdir, it produces the following warnings:
../../gllib/argp-help.c:1594:25: warning: dereference of NULL 'argp' [CWE-476]
[-Wanalyzer-null-dereference]
../../gllib/argp-help.c:1606:11: warning: dereference of NULL 'argp
Compiling a testdir with CC="gcc -fanalyzer" produced this warning:
../../gllib/immutable.c:333:3: warning: use of NULL 'wp' where non-null
expected [CWE-476] [-Wanalyzer-null-argument]
2021-04-30 Bruno Haible
immutable: Fix crash when immmalloc() fails.
Found by GCC 11 '-fa
Compiling a testdir with CC="gcc -fanalyzer" produced this warning:
gllib/supersede.c:63:3: warning: use of possibly-NULL 'temp_filename' where
non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
2021-04-30 Bruno Haible
supersede: Fix crash when malloc() fails.
F
* Bruno Haible:
>> I spent today on coming up with a workaround in glibc.
>
> These are the workarounds I can see:
> - Delay the planned changes in glibc by 5 years or so, to minimize
> the number of binaries out there that would crash. (Probably not what
> you want.)
Nah, those binarie
Adding timeout to all build operations automatically is probably too much
and too intrusive.
But in any case, it should be easy to add such a timeout to certain build
operations (e.g. downloading, running a compiler for which the halting
problem cannot be solved, testing a production binary, ...).
Marc Nieper-Wißkirchen writes:
> Moreover, use cases for a baked-in timeout are not restricted to tests. For
> example, I may want to restrict the build time of certain components in
> situations where a logical error may lead to infinite build times (a simple
> example is that of a Scheme compil
Dear Bruno, dear Simon,
thank you for your replies.
I understand that valgrind-tests and the proposed "timeout-tests" solution
are not completely equivalent. Nevertheless, I still think that some
timeout functionality provided by Gnulib would be useful.
Bruno's solution
**
#if HAVE_DECL_ALARM
Bruno Haible writes:
> So, I don't think the "let's treat timeout like valgrind" approach is going
> to work. Instead, you need to design a way to deal with timeouts,
> independently.
Hi! I think Marc's request for functionality to introduce timeouts for
self-tests is a good one. However I re
