From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11882 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: open issues Date: Wed, 30 Aug 2017 16:10:18 -0400 Message-ID: <20170830201018.GF1627@brightrain.aerifal.cx> References: <20170827043606.GQ15263@port70.net> <20170830020652.GD1627@brightrain.aerifal.cx> <1AC2E125-EED7-4EA1-AC9F-B08BA7BD494D@trust-in-soft.com> <20170830192038.GE1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1504123835 19508 195.159.176.226 (30 Aug 2017 20:10:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 30 Aug 2017 20:10:35 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11895-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 30 22:10:28 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dn9Jh-0004ck-AU for gllmg-musl@m.gmane.org; Wed, 30 Aug 2017 22:10:25 +0200 Original-Received: (qmail 3276 invoked by uid 550); 30 Aug 2017 20:10:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3258 invoked from network); 30 Aug 2017 20:10:29 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11882 Archived-At: On Wed, Aug 30, 2017 at 10:37:44PM +0300, Alexander Monakov wrote: > On Wed, 30 Aug 2017, Rich Felker wrote: > > Great find. I wonder if compiler/diagnostic tool ppl are aware of this > > extension to the C language that XSI imposes. It definitely affects > > things like UBSan, and of course compilers' optimization based on > > assumptions that UB doesn't happen. > > If musl is going to use this throughout the implementation, I think it > should be documented somewhere: it's of course fair game to use this > guarantee in implementation of interfaces that are themselves XSI-shaded, > but using it to implement more basic interfaces is less obviously so. Have you looked at the specific issue in question? It's scanf's handling of %n$ positional args. If we want to make scanf non-dependent on this property of va_arg when called without this form of arguments, we need to add significant additional code to track and match the pointer types for each arg. I'm not opposed to that but it's nontrivial work. I'd rather *not* make use of this property of va_arg gratuitously in other parts of musl, since I find it rather contrary to the intent of the language. Rich