From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98517 invoked by alias); 29 Sep 2015 16:50:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 98473 invoked by uid 89); 29 Sep 2015 16:50:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-qg0-f43.google.com Received: from mail-qg0-f43.google.com (HELO mail-qg0-f43.google.com) (209.85.192.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 29 Sep 2015 16:50:53 +0000 Received: by qgt47 with SMTP id 47so11426312qgt.2; Tue, 29 Sep 2015 09:50:51 -0700 (PDT) X-Received: by 10.140.202.210 with SMTP id x201mr32508912qha.0.1443545451664; Tue, 29 Sep 2015 09:50:51 -0700 (PDT) Received: from [192.168.0.26] (97-124-165-221.hlrn.qwest.net. [97.124.165.221]) by smtp.gmail.com with ESMTPSA id 78sm9547195qhd.40.2015.09.29.09.50.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2015 09:50:50 -0700 (PDT) Message-ID: <560AC168.5010500@gmail.com> Date: Tue, 29 Sep 2015 17:28:00 -0000 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jakub Jelinek , Jonathan Wakely CC: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [patch] Leave errno unchanged by successful std::stoi etc References: <20150929151541.GZ12094@redhat.com> <20150929152515.GJ1847@tucnak.redhat.com> <20150929161020.GA12094@redhat.com> <20150929161520.GK1847@tucnak.redhat.com> In-Reply-To: <20150929161520.GK1847@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg02239.txt.bz2 On 09/29/2015 10:15 AM, Jakub Jelinek wrote: > On Tue, Sep 29, 2015 at 05:10:20PM +0100, Jonathan Wakely wrote: >>> That looks wrong to me, you only restore errno if you don't throw :(. >>> If you throw, then errno might remain 0, which is IMHO undesirable. >> >> My thinking was that a failed conversion that throws an exception >> should be allowed to modify errno, and that the second case sets it to >> ERANGE sometimes anyway. > > Well, you can modify errno, you just shouldn't change it from non-zero to > zero as far as the user is concerned. > > http://pubs.opengroup.org/onlinepubs/009695399/functions/errno.html > "No function in this volume of IEEE Std 1003.1-2001 shall set errno to 0." > Of course, this part of STL is not POSIX, still, as you said, it would be > nice to guarantee the same. FWIW, I agree. It's a helpful property. If libstdc++ provides the POSIC/C guarantee it would be nice to document it in the manual. That said, this part of the C++ spec (stoi and related) is specified to such a level of detail that one might argue that the functions aren't allowed to reset errno in an observable way. As an aside, I objected to this specification when it was first proposed, not because of the errno guarantee, but because the functions were meant to be light-weight, efficient, and certainly thread-safe means of converting strings to numbers. Specifying their effects as opposed to their postconditions means that can't be implemented independent of strtol and the C locale, which makes them anything but light-weight, and prone to data races in programs that call setlocale. Martin