View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000453 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2011-05-27 10:59 | 2013-04-16 13:06 |
Reporter | geoffclare | Assigned To | ajosey | ||
Priority | normal | Severity | Objection | Type | Error |
Status | Closed | Resolution | Accepted | ||
Name | Geoff Clare | ||||
Organization | The Open Group | ||||
User Reference | |||||
Section | strtol | ||||
Page Number | 2044 | ||||
Line Number | 64794 | ||||
Interp Status | Approved | ||||
Final Accepted Text | See 0000453:0000811 | ||||
Summary | 0000453: strtol() EINVAL problems | ||||
Description | The RETURN VALUE section on the strtol() page says: If no conversion could be performed, 0 shall be returned [CX]and errno may be set to [EINVAL].[/CX] This EINVAL case is not mentioned in the description of EINVAL in the ERRORS section, which just says "The value of base is not supported." Another issue is that this unsupported base error seems to be distinct from the "no conversion could be performed" case mentioned in the RETURN VALUE section, and therefore the return value is unspecified when base is not supported. Likewise the following text regarding endptr does not apply to the unsupported base error: If the subject sequence is empty or does not have the expected form, no conversion is performed; the value of str is stored in the object pointed to by endptr, provided that endptr is not a null pointer. Finally, an editorial change from "is stored" to "shall be stored" is needed. Some (but not all) of these problems also affect strtoul(). Notably, strtoul() has the unsupported base error as "shall fail" instead of "may fail". Changes to the RETURN VALUE and ERRORS sections on the strtoimax() page are also needed. Possible ways to fix the problems with unsupported base values are: 1. Mandate return 0 and setting errno to EINVAL if base is unsupported but leave the value of *endptr unspecified. Since setting errno is already mandated for strtoul(), and not specifying the return value is probably just an oversight, I think this is likely to be the preferred option. All of the implementations I tried already behave this way. 2. Make the return 0 and endptr requirements also apply to the unsupported base error, and leave errno setting optional. This has the advantage that applications can check the value of *endptr without first checking for an EINVAL error (if they have not ensured that base has a supported value). However, it is not existing practice on at least one implementation: glibc does not update *endptr. 3. Remove all text relating to unsupported base values. The default rules about invalid function arguments would then apply, making the behaviour undefined (as in the C Standard). The proposed edits are for option 1. | ||||
Desired Action | At page 2044 line 64778 section strtol change: the value of str is stored to: the value of str shall be stored At page 2044 line 64785 section strtol page 2049 line 64889 section strtoul after: If no conversion could be performed, 0 shall be returned [CX]and errno may be set to [EINVAL][/CX]. add: [CX]If the value of base is not supported, 0 shall be returned and errno shall be set to [EINVAL].[/CX] At page 2039 line 64605 section strtoimax change: If no conversion could be performed, zero shall be returned. to: If no conversion could be performed, 0 shall be returned [CX]and errno may be set to [EINVAL][/CX]. [CX]If the value of base is not supported, 0 shall be returned and errno shall be set to [EINVAL].[/CX] At page 2039 line 64613 section strtoimax page 2044 line 64794 section strtol move: [EINVAL] The value of base is not supported. to before the [ERANGE] error, and in the strtoimax() case add CX shading to the line. At page 2039 line 64612 section strtoimax page 2044 line 64793 section strtol after: "These functions may fail if:" add: [EINVAL] No conversion could be performed. At page 2039 line 64617 section strtoimax page 2044 line 64798 section strtol page 2049 line 64902 section strtoul change the APPLICATION USAGE section from: None. to: Since the value of *endptr is unspecified if the value of base is not supported, applications should either ensure that base has a supported value (0 or between 2 and 36) before the call, or check for an [EINVAL] error before examining *endptr. | ||||
Tags | tc1-2008 |
|
Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- The DESCRIPTION section says an error may occur, but the ERRORS section does not describe the error that may occur. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the changes suggested in the Desired Action. |
|
Interpretation proposed 16 June 2011 for final 30 day review |
|
The interpretation is now approved. |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-05-27 10:59 | geoffclare | New Issue | |
2011-05-27 10:59 | geoffclare | Status | New => Under Review |
2011-05-27 10:59 | geoffclare | Assigned To | => ajosey |
2011-05-27 10:59 | geoffclare | Name | => Geoff Clare |
2011-05-27 10:59 | geoffclare | Organization | => The Open Group |
2011-05-27 10:59 | geoffclare | Section | => strtol |
2011-05-27 10:59 | geoffclare | Page Number | => 2044 |
2011-05-27 10:59 | geoffclare | Line Number | => 64794 |
2011-05-27 10:59 | geoffclare | Interp Status | => --- |
2011-06-09 16:25 | Don Cragun | Interp Status | --- => Pending |
2011-06-09 16:25 | Don Cragun | Note Added: 0000811 | |
2011-06-09 16:25 | Don Cragun | Status | Under Review => Interpretation Required |
2011-06-09 16:25 | Don Cragun | Resolution | Open => Accepted |
2011-06-09 16:25 | Don Cragun | Description Updated | |
2011-06-09 16:25 | Don Cragun | Desired Action Updated | |
2011-06-09 16:26 | Don Cragun | Tag Attached: tc1-2008 | |
2011-06-09 16:26 | Don Cragun | Final Accepted Text | => See 0000453:0000811 |
2011-06-16 10:18 | ajosey | Interp Status | Pending => Proposed |
2011-06-16 10:18 | ajosey | Note Added: 0000854 | |
2011-07-29 06:12 | ajosey | Interp Status | Proposed => Approved |
2011-07-29 06:12 | ajosey | Note Added: 0000898 | |
2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |