Title
Reporting out-of-bound values on numeric string conversions
Status
c++14
Section
[string.conversions]
Submitter
Alisdair Meredith

Created on 2010-07-19.00:00:00 last changed 123 months ago

Messages

Date: 2010-11-07.17:36:56

Proposed resolution:

21.5p3 [string.conversions]

int stoi(const string& str, size_t *idx = 0, int base = 10);
long stol(const string& str, size_t *idx = 0, int base = 10);
unsigned long stoul(const string& str, size_t *idx = 0, int base = 10);
long long stoll(const string& str, size_t *idx = 0, int base = 10);
unsigned long long stoull(const string& str, size_t *idx = 0, int base = 10);

...

3 Throws: invalid_argument if strtol, strtoul, strtoll, or strtoull reports that no conversion could be performed. Throws out_of_range if strtol, strtoul, strtoll or strtoull sets errno to ERANGE, or if the converted value is outside the range of representable values for the return type.

21.5p6 [string.conversions]

float stof(const string& str, size_t *idx = 0);
double stod(const string& str, size_t *idx = 0);
long double stold(const string& str, size_t *idx = 0);

...

6 Throws: invalid_argument if strtod or strtold reports that no conversion could be performed. Throws out_of_range if strtod or strtold sets errno to ERANGE or if the converted value is outside the range of representable values for the return type.

Date: 2011-03-07.11:36:48

The functions (w)stoi and (w)stof are specified in terms of calling C library APIs for potentially wider types. The integer and floating-point versions have subtly different behaviour when reading values that are too large to convert. The floating point case will throw out_of_bound if the read value is too large to convert to the wider type used in the implementation, but behaviour is undefined if the converted value cannot narrow to a float. The integer case will throw out_of_bounds if the converted value cannot be represented in the narrower type, but throws invalid_argument, rather than out_of_range, if the conversion to the wider type fails due to overflow.

Suggest that the Throws clause for both specifications should be consistent, supporting the same set of fail-modes with the matching set of exceptions.

History
Date User Action Args
2014-02-20 13:20:35adminsetstatus: wp -> c++14
2012-02-12 18:36:43adminsetstatus: voting -> wp
2012-02-09 04:07:48adminsetstatus: ready -> voting
2011-09-06 13:05:28adminsetstatus: voting -> ready
2011-08-16 10:45:53adminsetstatus: ready -> voting
2011-03-24 16:58:37adminsetstatus: review -> ready
2010-11-13 23:03:59adminsetstatus: new -> review
2010-11-07 17:36:56adminsetmessages: + msg5301
2010-07-19 00:00:00admincreate