View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00007001003.1(2008)/Issue 7System Interfacespublic2013-05-19 18:122024-06-11 08:52
Reporterfbauzac Assigned Toajosey  
PrioritynormalSeverityCommentTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
NameFabrice Bauzac
Organization
User Reference
Sectionstrtoul
Page Numberna
Line Numberna
Interp Status---
Final Accepted Text0000700:0006256
Summary0000700: Clarify strtoul's behaviour on strings representing negative numbers
DescriptionIn which cases does strtoul (and other strtou* functions) fail with ERANGE? How is the range check performed?

This ticket follows the discussion about strtoul on austin-group-l in May 2013.

The RETURN VALUE section in
http://pubs.opengroup.org/onlinepubs/009696799/functions/strtoul.html
says:
If the correct value is outside the range of representable values, {ULONG_MAX} or {ULLONG_MAX} shall be returned and errno set to [ERANGE].

Some people understand this as "if the value I read (the correct value) is outside the [0, ULONG_MAX] range, then strtoul fails with ERANGE".

However, it seems that many implementations do the following:
1. Read independently the optional sign and the subject [0-9]+ sequence
2. If the subject sequence fits in the unsigned long type, then store it in an unsigned long variable. Otherwise (outside the [0, ULONG_MAX] range), fail with ERANGE.
3. If there was a minus sign, then apply negation on the unsigned long variable as if it were a signed long.

According to the discussion on the austin-group-l mailing list, it looks like this is what the POSIX standard (and the C standard) intend to specify. But it looks like it is not clear enough in the specification.
Desired ActionIn section "RETURN VALUE", replace
- If the correct value is outside the range of representable values
with either of:
+ If the nonnegated value is outside the range of representable values
or
+ If the unnegated value is outside the range of representable values
or
+ If the value before potential negation is outside the range of representable values
or
+ If the absolute value is outside the range of representable values
or something similar
Tagsapplied_after_i8d3, c99, tc3-2008

Activities

nick

2023-02-16 16:41

manager   bugnote:0006150

Last edited: 2023-02-16 16:45

 During the 2022-02-13 - 2022-02-17 meeting, WG14 accepted paper https://www.open-std.org/jtc1/sc22/WG14/www/docs/n3107.pdf (16 in favor, 0 against, 0 abstains).

The C23 standard will contain the following change:

Replace the following sentence from Subclause 7.24.1.7, “The strtol, strtoll, strtoul, and strtoull
functions” paragraph 5:

If the subject sequence begins with a minus sign, the value resulting from the conversion is negated (in the return type).

with:

If the subject sequence begins with a minus sign, the resulting value is the negative of the converted value; for functions whose return type is an unsigned integer type this action is performed in the return type.

Replace the following sentence from Subclause 7.31.4.1.4, “The wcstol, wcstoll, wcstoul, and
wcstoull functions” paragraph 5:

If the subject sequence begins with a minus sign, the value resulting from the conversion is negated (in the return type).

with:

If the subject sequence begins with a minus sign, the resulting value is the negative of the converted value; for functions whose return type is an unsigned integer type this action is performed in the return type.

geoffclare

2023-04-06 16:30

manager   bugnote:0006256

On 2018 edition page 2081 line 66795 section strtol(), and
page 2277 line 72497 section wcstol(), change:
the value resulting from the conversion shall be negated.
to:
the resulting value shall be the negative of the converted value.

On 2018 edition page 2086 line 66909 section strtoul(), and
page 2284 line 72661 section wcstoul(), change:
the value resulting from the conversion shall be negated.
to:
the resulting value shall be the negative of the converted value; this action shall be performed in the return type.

Issue History

Date Modified Username Field Change
2013-05-19 18:12 fbauzac New Issue
2013-05-19 18:12 fbauzac Status New => Under Review
2013-05-19 18:12 fbauzac Assigned To => ajosey
2013-05-19 18:12 fbauzac Name => Fabrice Bauzac
2013-05-19 18:12 fbauzac Section => strtoul
2013-05-19 18:12 fbauzac Page Number => na
2013-05-19 18:12 fbauzac Line Number => na
2013-05-23 16:27 msbrown Project 1003.1(2004)/Issue 6 => 1003.1(2008)/Issue 7
2014-04-03 16:22 geoffclare Tag Attached: c99
2023-02-16 16:41 nick Note Added: 0006150
2023-02-16 16:42 nick Note Edited: 0006150
2023-02-16 16:44 nick Note Edited: 0006150
2023-02-16 16:45 nick Note Edited: 0006150
2023-04-06 16:30 geoffclare Note Added: 0006256
2023-04-06 16:31 geoffclare Interp Status => ---
2023-04-06 16:31 geoffclare Final Accepted Text => 0000700:0006256
2023-04-06 16:31 geoffclare Status Under Review => Resolved
2023-04-06 16:31 geoffclare Resolution Open => Accepted As Marked
2023-04-06 16:32 geoffclare Tag Attached: tc3-2008
2023-05-16 10:38 geoffclare Status Resolved => Applied
2023-05-16 10:39 geoffclare Tag Attached: applied_after_i8d3
2024-06-11 08:52 agadmin Status Applied => Closed