From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: enh <enh@google.com>, Martin Uecker <muecker@gwdg.de>
Cc: Alejandro Colomar <alx@kernel.org>,
Xi Ruoyao <xry111@xry111.site>, Andrew Pinski <pinskia@gmail.com>,
GNU libc development <libc-alpha@sourceware.org>,
Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Carlos O'Donell <carlos@redhat.com>,
Andreas Schwab <schwab@suse.de>,
Zack Weinberg <zack@owlfolio.org>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: _Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h)
Date: Tue, 8 Aug 2023 21:11:47 -0400 [thread overview]
Message-ID: <454482b7-6a19-680a-a6e4-5151917046f1@gotplt.org> (raw)
In-Reply-To: <CAJgzZopb5_fPCT7_Oovi+CDUjX17ULn+qgN70qYOxUpXCTRS4w@mail.gmail.com>
On 2023-08-08 20:14, enh wrote:
> (bionic maintainer here, mostly by accident...)
>
> yeah, we tried the GCC attributes once before with _disastrous_
> results (because GCC saw it as an excuse to delete explicit null
> checks, it broke all kinds of things). the clang attributes are
AFAICT based on earlier discussions around this patch, the NULL check
deletion anomalies in gcc seem to have been fixed recently.
> "better" in that they don't confuse two entirely separate notions ...
> but they're not "good" because the analysis is so limited. i think we
> were hoping for something more like the "used but not set" kind of
> diagnostic, but afaict it really only catches _direct_ use of a
> literal nullptr. so:
>
> foo(nullptr); // caught
>
> void* p = nullptr;
> foo(p); // not caught
>
> without getting on to anything fancy like:
>
> void* p;
> if (a) p = bar();
> foo(p);
>
> we've done all the annotations anyway, but we're not expecting to
> actually catch many bugs with them, and in fact did not catch any real
> bugs in AOSP while adding the annotations. (though we did find several
> "you're not _wrong_, but ..." bits of code :-) )
I believe it did catch a few issues in the glibc test cases when we
enabled fortification internally in addition to flagging several "you're
not _wrong_, but..." bits. In any case, it's only enabled with
fortification since we use that as a hint for wanting safer code.
> what i really want for christmas is the annotation that lets me say
> "this size_t argument tells you the size of this array argument" and
> actually does something usefully fortify-like with that. i've seen
> proposals like https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854/
> but i haven't seen anything i can use yet, so you -- who do use GCC
> which aiui has something along these lines already -- will find out
> what's good/bad about it before i do...
I think a lot of this is covered by __access__, __alloc_size__ and the
upcoming __counted_by__ attributes. There are still gaps that something
like -fbounds-safety would cover (I think -fsanitize=bounds and
-fsanitize=object-size further cover some of those gaps but there's a
general lack of confidence in using them in production due to
performance concerns; fbounds-safety has those concerns too AFAICT) but
that gap is getting narrower.
Thanks,
Sid
next prev parent reply other threads:[~2023-08-09 1:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230710161300.1678172-1-xry111@xry111.site>
[not found] ` <a3a0c195-1149-461b-807e-46eaa3d68fcc@app.fastmail.com>
[not found] ` <ed86d013-1df5-2880-3e39-0caf8f49a999@gotplt.org>
[not found] ` <1efbe0b2dd8fefffc945c6734222c7d6e04cf465.camel@xry111.site>
2023-07-10 20:14 ` Alejandro Colomar
2023-07-10 20:16 ` Alejandro Colomar
2023-08-08 10:01 ` Martin Uecker
2023-08-09 0:14 ` enh
2023-08-09 1:11 ` Siddhesh Poyarekar [this message]
2023-08-09 7:26 ` Martin Uecker
2023-08-09 10:42 ` ISO C's [static] (was: _Nullable and _Nonnull in GCC's analyzer) Alejandro Colomar
2023-08-09 12:03 ` Martin Uecker
2023-08-09 12:37 ` Alejandro Colomar
2023-08-09 14:24 ` Martin Uecker
2023-08-09 13:46 ` Xi Ruoyao
2023-08-11 23:34 ` _Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h) enh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=454482b7-6a19-680a-a6e4-5151917046f1@gotplt.org \
--to=siddhesh@gotplt.org \
--cc=adhemerval.zanella@linaro.org \
--cc=alx@kernel.org \
--cc=carlos@redhat.com \
--cc=enh@google.com \
--cc=gcc@gcc.gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=muecker@gwdg.de \
--cc=pinskia@gmail.com \
--cc=schwab@suse.de \
--cc=xry111@xry111.site \
--cc=zack@owlfolio.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).