public inbox for glibc-cvs@sourceware.org help / color / mirror / Atom feed
From: Paul Eggert <eggert@sourceware.org> To: glibc-cvs@sourceware.org Subject: [glibc] manual: update AddressSanitizer discussion Date: Sat, 8 Apr 2023 20:54:09 +0000 (GMT) [thread overview] Message-ID: <20230408205409.E0FED3858D33@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=54ae6d81c94364c1e13a5b8baef52b9e3475fedd commit 54ae6d81c94364c1e13a5b8baef52b9e3475fedd Author: Paul Eggert <eggert@cs.ucla.edu> Date: Sat Apr 8 13:51:26 2023 -0700 manual: update AddressSanitizer discussion * manual/string.texi (Truncating Strings): Update obsolescent reference and use the more-generic term “AddressSanitizer”. Mention fortification, too. -fcheck-pointer-bounds is no longer supported. Diff: --- manual/string.texi | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/manual/string.texi b/manual/string.texi index 57b804c1df..ad57265274 100644 --- a/manual/string.texi +++ b/manual/string.texi @@ -1088,11 +1088,10 @@ name, a truncated name can identify the wrong user. Although some buffer overruns can be prevented by manually replacing calls to copying functions with calls to truncation functions, there -are often easier and safer automatic techniques that cause buffer -overruns to reliably terminate a program, such as GCC's -@option{-fcheck-pointer-bounds} and @option{-fsanitize=address} -options. @xref{Debugging Options,, Options for Debugging Your Program -or GCC, gcc, Using GCC}. Because truncation functions can mask +are often easier and safer automatic techniques, such as fortification +(@pxref{Source Fortification}) and AddressSanitizer +(@pxref{Instrumentation Options,, Program Instrumentation Options, gcc, Using GCC}). +Because truncation functions can mask application bugs that would otherwise be caught by the automatic techniques, these functions should be used only when the application's underlying logic requires truncation.
reply other threads:[~2023-04-08 20:54 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20230408205409.E0FED3858D33@sourceware.org \ --to=eggert@sourceware.org \ --cc=glibc-cvs@sourceware.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: linkBe 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).