public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>,
	Zack Weinberg <zack@owlfolio.org>,
	 GNU libc development <libc-alpha@sourceware.org>
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	Carlos O'Donell <carlos@redhat.com>,
	"'Alejandro Colomar (man-pages)'" <alx.manpages@gmail.com>,
	 Andreas Schwab <schwab@suse.de>,
	David Malcolm <dmalcolm@redhat.com>
Subject: Re: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h
Date: Tue, 11 Jul 2023 03:35:19 +0800	[thread overview]
Message-ID: <de4b1987522a3f9e1e2eecc0aae47960e55cc203.camel@xry111.site> (raw)
In-Reply-To: <5d050e86-4c98-de22-5ef0-4cc9ead273d7@gotplt.org>

On Mon, 2023-07-10 at 15:31 -0400, Siddhesh Poyarekar wrote:
> On 2023-07-10 14:56, Zack Weinberg wrote:
> > > Would it be more acceptable to you if this gets wrapped into fortify,
> > > i.e. it gets enabled if _FORTIFY_SOURCE is defined?
> > 
> > I tend to agree with Xi that having the presence of __nonnull depend on
> > _FORTIFY_SOURCE would cause more problems than it solves.  Also, since
> > several Linux distributions enable _FORTIFY_SOURCE by default, we'd
> > still be risking significant breakage if we shipped that in 2.38.
> 
> I'm less concerned about the distribution breakage because they'll more 
> likely than not get fixed; in fact my suggestion to put it behind the 
> _FORTIFY_SOURCE wall was precisely for that reason.  I'd like us to weed 
> out such cases in the distribution and get them fixed rather than 
> maintaining status quo.  I'm relatively more concerned about 
> non-distribution applications that tend to, e.g. disable security 
> features because they see them as either performance hindrances or want 
> some legacy broken code to just work.
> 
> Of course, I'm not concerned enough about these applications (sorry) to 
> insist that it be put behind _FORTIFY_SOURCE, but I think it's a 
> reasonable compromise.  That doesn't directly solve the analyzer problem 
> though.  Maybe if it's OK to have the analyzer affect codegen, we could 
> have the analyzer define _FORTIFY_SOURCE=3 and thus enable additional 
> diagnostics too, like the __wur that also gets enabled only on 
> fortification.  Is that something worth considering?

Or can we just guard the __nonnull usage against __GNUC_PREREQ (x, 0)
where x is 12 or 13?  In the recent GCC releases the optimizer won't
kill a side effect before an UB so it should be much safer (see my reply
to Zack), and it's unlikely they'll use the latest GCC for some legacy
broken code.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2023-07-10 19:35 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-10 16:13 Xi Ruoyao
2023-07-10 17:12 ` Zack Weinberg
2023-07-10 17:27   ` Xi Ruoyao
2023-07-10 19:06     ` Zack Weinberg
2023-07-10 19:31       ` Xi Ruoyao
2023-07-10 17:51   ` Siddhesh Poyarekar
2023-07-10 18:41     ` Xi Ruoyao
2023-07-10 20:14       ` _Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h) 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
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
2023-07-10 18:56     ` [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h Zack Weinberg
2023-07-10 19:31       ` Siddhesh Poyarekar
2023-07-10 19:35         ` Xi Ruoyao [this message]
2023-07-10 19:46           ` Siddhesh Poyarekar
2023-07-10 20:23             ` Xi Ruoyao
2023-07-10 20:33               ` Jeff Law
2023-07-10 20:44                 ` Xi Ruoyao
2023-07-10 20:55                 ` Zack Weinberg
2023-07-10 21:03                   ` Xi Ruoyao
2023-07-10 21:22                     ` Zack Weinberg
2023-07-10 21:33                       ` Xi Ruoyao
2023-07-11 19:12                         ` Zack Weinberg
2023-07-11 20:12                           ` Siddhesh Poyarekar
2023-07-12  8:59                             ` Xi Ruoyao
2023-07-10 22:09                       ` Paul Eggert
2023-07-11 19:18                         ` Zack Weinberg
2023-07-11 20:45                           ` Jeff Law
2023-07-11 23:59                             ` Paul Eggert
2023-07-12  2:40                               ` Jeff Law
2023-07-10 22:48                       ` Siddhesh Poyarekar
2023-07-11  0:45                         ` Sam James
2023-07-10 21:51                   ` Jeff Law
2023-07-11 13:03                     ` Cristian Rodríguez
2023-07-10 22:34                 ` Siddhesh Poyarekar
2023-07-10 22:59                   ` Jeff Law
2023-07-11  0:51         ` Sam James

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=de4b1987522a3f9e1e2eecc0aae47960e55cc203.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=adhemerval.zanella@linaro.org \
    --cc=alx.manpages@gmail.com \
    --cc=carlos@redhat.com \
    --cc=dmalcolm@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=schwab@suse.de \
    --cc=siddhesh@gotplt.org \
    --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).