Re: [RFC PATCH 07/15] strbuf.c: placate -fanalyzer in strbuf_grow()
- From
- Phillip Wood <phillip.wood@talktalk.net>
- Date
- Jun 4, 2022, 12:46 UTC
- Message-ID
- <870925774.539833.1654346793623@apps.talktalk.co.uk>
- In-Reply-To
- <RFC-patch-07.15-cf1a5f3ed0f-20220603T183608Z-avarab@gmail.com>
Hi Ævar
[This is an old address that I only have webmail access to, please use phillip.wood@dunelm.org.uk when cc'ing me]
Show 27 quoted lines
> On 03 June 2022 at 19:37 Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> Change the strbuf_grow() function so that GCC v12's -fanalyze doesn't
> yell at us about sb->buf[0] dereferencing NULL, this also makes this
> code easier to follow.
>
> This BUG() should be unreachable since the state of our "sb->buf" and
> "sb->alloc" goes hand-in-hand, but -fanalyzer isn't smart enough to
> know that, and adding the BUG() also makes it clearer to human readers
> that that's what happens here.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
> strbuf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/strbuf.c b/strbuf.c
> index dd9eb85527a..61c4630aeeb 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -97,6 +97,8 @@ void strbuf_grow(struct strbuf *sb, size_t extra)
> if (new_buf)
> sb->buf = NULL;
> ALLOC_GROW(sb->buf, sb->len + extra + 1, sb->alloc);
> + if (new_buf && !sb->buf)
> + BUG("for a new buffer ALLOC_GROW() should always do work!");This is a bit ugly, have you tried adding __attribute__((malloc (free), returns_nonnull)) to xmalloc() and xrealloc() ?
Best Wishes
Phillip
Show 6 quoted lines
> if (new_buf) > sb->buf[0] = '\0'; > } > -- > 2.36.1.1124.g577fa9c2ebd >