From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64011 invoked by alias); 24 Mar 2017 18:15:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 60506 invoked by uid 89); 24 Mar 2017 18:15:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=Austin, austin, cares, D*cx X-HELO: brightrain.aerifal.cx Received: from 216-197-64-233.tingfiber.com (HELO brightrain.aerifal.cx) (216.197.64.233) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Mar 2017 18:15:11 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1crTjO-0007Pc-00; Fri, 24 Mar 2017 18:14:34 +0000 Date: Fri, 24 Mar 2017 18:15:00 -0000 From: Rich Felker To: Andreas Schwab Cc: Yousong Zhou , Pedro Alves , gdb-patches@sourceware.org, musl@lists.openwall.com Subject: Re: [musl] Re: [PATCH] Fix invalid sigprocmask call Message-ID: <20170324181434.GH17319@brightrain.aerifal.cx> References: <1490324519-11228-1-git-send-email-yszhou4tech@gmail.com> <2b0bab84-e36e-e109-5444-dc84369dddce@redhat.com> <39f28782-65e8-0f52-3c8f-134a6f05788b@redhat.com> <20170324153530.GF17319@brightrain.aerifal.cx> <8737e24m0s.fsf@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8737e24m0s.fsf@linux-m68k.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2017-03/txt/msg00452.txt.bz2 On Fri, Mar 24, 2017 at 06:33:55PM +0100, Andreas Schwab wrote: > On Mär 24 2017, Rich Felker wrote: > > > If you file a report and it's deemed a bug in the standard and > > changed, I'm happy to change this on the musl side. Just keep me > > posted on what happens. I don't have any preference on what the > > behavior "should" be here (IMO imposing a behavior when the caller has > > violated constraints like passed a wrong value for how is pointless > > anyway) but I do want to conform to the standard. > > The standard says that how must be ignored if set is NULL. The standard says in one place that it's "not significant" if "set is a null pointer", but then in another that the call "shall fail" if "the how argument is not equal to one of the defined values". The former could be interpreted either as allowing any of the 3 defined values (doesn't matter which) for how when set is null, or allowing any value at all; the latter interpretation conflicts with the normative errors section. Anyway I don't think language-lawyering this offline is productive. If anyone really cares about the behavior one way or the other, take it to the Austin Group tracker where the decision-makers will see it. Rich