public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/104929] UBSAN: false positive with sprintf
Date: Tue, 15 Mar 2022 09:56:05 +0000	[thread overview]
Message-ID: <bug-104929-4-BY4q3a53es@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-104929-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104929

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In this particular case the problem is that UBSAN adds the non-NULL tests, so
the IL becomes if (!s) __ubsan_handle_nonnull_arg (...); sprintf(s,  " "); if
(!s) __ubsan_handle_nonnull_arg (...); return __builtin_strlen(s);
and then jump threading thinks it is a good idea to thread it, so turns it into
if (!s) { __ubsan_handle_nonnull_arg (...); sprintf(NULL, " ");
__ubsan_handle_nonnull_arg (...); } else sprintf(s, " ");
and that is why the warning is emitted (pain of all the middle-end warnings).
The ways out of this might be convince jump threading to punt in such cases
(when  those are clearly ubsan tests) because we expect them to be extremely
unlikely,
or use some new internal function from between the ubsan pass and sanopt, where
the test for non-NULL wouldn't be explicit in the IL until very late (that
would also prevent the jump threading), or during the jump threading when we
detect these ubsan-ish tests suppress some of the warnings on the threaded
stmts.

      parent reply	other threads:[~2022-03-15  9:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15  9:25 [Bug sanitizer/104929] New: " jengelh at inai dot de
2022-03-15  9:27 ` [Bug sanitizer/104929] " marxin at gcc dot gnu.org
2022-03-15  9:42 ` schwab@linux-m68k.org
2022-03-15  9:56 ` jakub at gcc dot gnu.org [this message]

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=bug-104929-4-BY4q3a53es@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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).