View Issue Details

IDProjectCategoryView StatusLast Update
00004531003.1(2008)/Issue 7System Interfacespublic2013-04-16 13:06
Reportergeoffclare Assigned Toajosey  
PrioritynormalSeverityObjectionTypeError
Status ClosedResolutionAccepted 
NameGeoff Clare
OrganizationThe Open Group
User Reference
Sectionstrtol
Page Number2044
Line Number64794
Interp StatusApproved
Final Accepted TextSee 0000453:0000811
Summary0000453: strtol() EINVAL problems
DescriptionThe 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 ActionAt 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.
Tagstc1-2008

Activities

Don Cragun

2011-06-09 16:25

manager   bugnote:0000811

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.

ajosey

2011-06-16 10:18

manager   bugnote:0000854

Interpretation proposed 16 June 2011 for final 30 day review

ajosey

2011-07-29 06:12

manager   bugnote:0000898

The interpretation is now approved.

Issue History

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