0001353: strftime errno issues - Austin Group Defect Tracker

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Category

Severity

Type

Date Submitted

Last Update

0001353

[Issue 8 drafts] System Interfaces

Objection

Error

2020-06-28 15:10

2020-09-03 15:49

Reporter

dennisw

View Status

public

Assigned To

Priority

normal

Resolution

Duplicate

Status

Closed

Product Version

Draft 1

Name

Dennis Wölfing

Organization

User Reference

Section

strftime

Page Number

1964-1965

Line Number

63875-63884

Final Accepted Text

Summary

0001353: strftime errno issues

Description

Bug 0000169 added the requirement that strftime sets errno on failure. However there are three issues with this.
1. The RETURN VALUE section implies that strftime can only fail if the buffer is not big enough, which contradicts the ERRORS section.
2. The draft standard now requires that strftime sets errno if the result does not fit into the buffer but it does not specify which value errno is set to.
3. Even tough strftime is required to set errno on failure an application cannot reliably know whether errno contains a meaningful value because a return value of 0 may also mean that a successful conversion resulted in an empty string.

I don't know of any POSIX conforming implementations that currently set errno on failure. However I found that the Windows implementation of strftime sets errno to ERANGE when the buffer is too small.
Note that implementations that currently do not set errno already need to change in order to conform to the draft 1 requirements.

Desired Action

On page 1964 after line 63875 add these two paragraphs with CX shading:

These functions shall not change the setting of errno if successful.

Since 0 is returned on error and is also a valid return on success, an application wishing to check
for error situations should set errno to 0, then call strftime( ) or strftime_l( ), then check errno.

On page 1964 lines 63877-63880 change

If the total number of resulting bytes including the terminating null byte is not more than
maxsize, these functions shall return the number of bytes placed into the array pointed to by s,
not including the terminating NUL character. Otherwise, 0 shall be returned, [CX]errno shall be set to
indicate the error,[/CX] and the contents of the array are unspecified.

If all conversions are successful and the total number of resulting bytes including the terminating null byte is not more than
maxsize, these functions shall return the number of bytes placed into the array pointed to by s,
not including the terminating NUL character. Otherwise, 0 shall be returned, [CX]errno shall be set to
indicate the error,[/CX] and the contents of the array are unspecified.

On page 1965 after line 63884 add with CX shading:

[ERANGE]
The total number of resulting bytes including the terminating null byte is more than maxsize.

Tags

No tags attached.

Attached Files

Relationships

duplicate of

0001386

Applied

strftime RETURN VALUE and ERRORS problems

Notes
(0004903) eggert (reporter) 2020-08-08 19:51 edited on: 2020-08-08 22:44	Aarrgh, I submitted an objection 0001386 along similar lines, before noticing this objection. The two objections mainly agree. My proposal required errno to be preserved on success only when the returned value is 0 (as that's all that applications need), but the stronger requirement proposed here is also fine (and the tzdb reference implementation also satisfies the stronger requirement). Also, I suggested that EOVERFLOW be a "may fail" rather than "shall fail" error.

Issue History
Date Modified	Username	Field	Change
2020-06-28 15:10	dennisw	New Issue
2020-06-28 15:10	dennisw	Name	=> Dennis Wölfing
2020-06-28 15:10	dennisw	Section	=> strftime
2020-06-28 15:10	dennisw	Page Number	=> 1964-1965
2020-06-28 15:10	dennisw	Line Number	=> 63875-63884
2020-08-08 19:51	eggert	Note Added: 0004903
2020-08-08 22:41	Don Cragun	Relationship added	related to 0001386
2020-08-08 22:44	Don Cragun	Note Edited: 0004903
2020-09-03 15:49	Don Cragun	Status	New => Closed
2020-09-03 15:49	Don Cragun	Resolution	Open => Duplicate
2020-09-03 15:49	Don Cragun	Relationship replaced	duplicate of 0001386

Mantis 1.1.6[^]