|Anonymous | Login||2023-06-11 00:15 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||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|
|Status||Closed||Product Version||Draft 1|
|Final Accepted Text|
|Summary||0001353: strftime errno issues|
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.
On page 1964 after line 63875 add these two paragraphs with CX shading:
These functions shall not change the setting of errno if successful.
On page 1964 lines 63877-63880 change
If the total number of resulting bytes including the terminating null byte is not more thanto
If all conversions are successful and the total number of resulting bytes including the terminating null byte is not more than
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.|
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.
|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[^] Copyright © 2000 - 2008 Mantis Group|