> Find attached a log built with -DGCC_LINT.
I've looked through part of the reports and found the following:
1) Interesting findings:
xmalloc.c:113:10: warning: use of possibly-NULL '' where non-null
expected [CWE-690] [-Wanalyzer-possible-null-argument]
Since xmalloc (0) may be NULL, xmemdup
I agree with Paul, for three reasons:
* We, the developers, should decide how our programs look like. It's not
only a question of pride - even if that pride is only about having save a
'xorl %eax,%eax' instruction. It's a question about whether we use the
tools for our benefit, or we become
* lib/careadlinkat.c (careadlinkat) [GCC_LINT]:
Massage the code so that it’s closer to what it was before
the GCC 10.1.0 workaround was introduced. This fixes
a loop when !buffer and the bug workaround is in effect.
Remove unnecessary casts. Defend in a different way
against (buffer && !buffer_s
On 5/11/20 11:37 AM, Bruno Haible wrote:
POSIX [2][3], macOS [4], FreeBSD [5], Solaris [6] don't support this 'e' flag.
Although it _is_ slated to be added in a future revision of POSIX:
https://www.austingroupbugs.net/view.php?id=411
How about using open() with O_CLOEXEC, and then fdopen
On 5/11/20 12:43 AM, Kamil Dudka wrote:
> It is usually bad idea to use different versions of source code for compilers
> and for static analyzers.
Yes, I don't like it either. The patch I installed was particularly bad, since
the workaround code was buggy. My only excuse is that the GCC bug itse
Hi Tim,
> i would like to ask for your expert knowledge.
>
> How to prevent file descriptor leaks in a multi-threaded application
> that fork+exec. Quick answer is surely "use O_CLOEXEC" to close those
> file descriptors on exec.
>
> But how does this work with fopen in a portable way ?
> GNU li
Hi,
i would like to ask for your expert knowledge.
How to prevent file descriptor leaks in a multi-threaded application
that fork+exec. Quick answer is surely "use O_CLOEXEC" to close those
file descriptors on exec.
But how does this work with fopen in a portable way ?
GNU libc has the 'e' flag
> +If you, by mistake, use @code{LIB<@var{NAME}>} instead of
> +@code{LTLIB<@var{NAME}>} when linking with libtool, you will observe
that the
> +binaries created in the build dir will prefer the shared libraries
in the
> +installation directories over the shar
Hi José,
> +If you, by mistake, use @code{LIB<@var{NAME}>} instead of
> +@code{LTLIB<@var{NAME}>} when linking with libtool, you will observe
> that the
> +binaries created in the build dir will prefer the shared libraries in the
> +installation directories over the shared librari
On Sunday, May 10, 2020 3:13:41 AM CEST Paul Eggert wrote:
> The first bug in that output:
>
> cc1: warning: function may return address of local variable
> [-Wreturn-local-addr] lib/careadlinkat.c:73:8: note: declared here
>73 | char stack_buf[1024];
>
> |^
>
> This
diff --git a/doc/havelib.texi b/doc/havelib.texi
index a776d52..59126c7 100644
--- a/doc/havelib.texi
+++ b/doc/havelib.texi
@@ -79,6 +79,17 @@ when linking with libtool. Both
@code{LTLIB<@var{NAME}>} and
@samp{-Wl,-rpath}, @code{LTLIB<@var{NAME}>} contains platform
11 matches
Mail list logo
