This is the mail archive of the
mailing list for the libstdc++ project.
Re: [patch] Leave errno unchanged by successful std::stoi etc
- From: Martin Sebor <msebor at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Tue, 29 Sep 2015 10:50:48 -0600
- Subject: Re: [patch] Leave errno unchanged by successful std::stoi etc
- Authentication-results: sourceware.org; auth=none
- References: <20150929151541 dot GZ12094 at redhat dot com> <20150929152515 dot GJ1847 at tucnak dot redhat dot com> <20150929161020 dot GA12094 at redhat dot com> <20150929161520 dot GK1847 at tucnak dot redhat dot com>
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.
"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
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.