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: 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).