From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63146 invoked by alias); 24 Mar 2017 16:41:42 -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 63135 invoked by uid 89); 24 Mar 2017 16:41:42 -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=Hx-languages-length:997, H*F: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 16:41:41 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1crSHP-0007BE-00; Fri, 24 Mar 2017 16:41:35 +0000 Date: Fri, 24 Mar 2017 16:41:00 -0000 From: Rich Felker To: Pedro Alves Cc: Yousong Zhou , gdb-patches@sourceware.org, musl@lists.openwall.com Subject: Re: [musl] Re: [PATCH] Fix invalid sigprocmask call Message-ID: <20170324164135.GG17319@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> <2db8b8b5-8145-19e2-238b-cf5e40108cba@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2db8b8b5-8145-19e2-238b-cf5e40108cba@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2017-03/txt/msg00449.txt.bz2 On Fri, Mar 24, 2017 at 03:52:08PM +0000, Pedro Alves wrote: > On 03/24/2017 03:35 PM, 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. > > Keep me posted as well. > > > 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. > > IMO, no constrains were violated. I don't mean a constraint in the formal sense. Rather I'm talking about the whole class of errors that are "programming mistake caused a wrong/nonsensical value to be passed for an argument" as opposed to errors that can legitimately happen in a non-buggy program (out of memory, no such file, limit exceeded, invalid input, etc.). Sorry I wasn't clear. Rich