|Anonymous | Login||2020-08-13 11:26 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000618||[1003.1(2008)/Issue 7] System Interfaces||Objection||Error||2012-10-02 19:28||2012-10-03 15:29|
|Final Accepted Text|
|Summary||0000618: require isatty and friends to set errno on failure|
0000503 (for Issue 7 TC2) dealt with the fact that several functions dealing with pseudo-tty have historically reported failure without setting errno, leading to some unfortunate use of "may set errno" wording. However, this is a dis-service to applications, and this situation should be tightened to require an actual error for Issue 8. On the other hand, existing implementations that do report errors differ on a per-function basis whether errors are reported as EINVAL or ENOTTY (for example, glibc documents that it uses EINVAL for both isatty and grantpt, although POSIX suggests ENOTTY for isatty and EINVAL for grantpt), so allowing both errors makes it easier to implement these functions from the same building blocks.
Note that some existing implementations will have to add code to comply with this new requirement; but also note that at least the upcoming FreeBSD 9 release has already made a move in this direction compared to the state of FreeBSD 8.2, as spurred by the mail associated with bug 503, proving that it is relatively easy to add this to existing implementations.
See also the reflector traffic on the issue, such as sequence 16677. One of the alternatives in that thread was the possibility of permitting existing implementations that leave errno unchanged on failure, by merely documenting that at an application wishing to learn if a particular error was detected must first set errno to 0, and if failure is reported but errno is unchanged, then the cause of the failure is unknown. But as that is less friendly to applications, I did not use it in the Desired Action.
[These edits are to the text prior to inclusion of Note: 0001004 from bug 503, although it should be fairly obvious how to edit ptsname if starting from TC2 text]
At line 36469 [XSH grantpt ERRORS], change "may fail" to "shall fail"
At line 36471 [XSH grantpt ERRORS], change "[EINVAL]" to "[EINVAL] or [ENOTTY]".
At line 38060 [XSH isatty RETURN VALUE], change "may set errno" to "shall set errno".
At line 38062 [XSH isatty ERRORS], change "may fail" to "shall fail".
At line 38064 [XSH isatty ERRORS], change "[ENOTTY]" to "[EINVAL] or [ENOTTY]".
At line 54750 [XSH ptsname RETURN VALUE], after "shall return a null pointer", add ", and shall set errno".
At line 54754 [XSH ptsname ERRORS], replace "No errors are defined." with:
The ptsname( ) function shall fail if:
[EBADF] The fildes argument is not a valid file descriptor.
[EINVAL] or [ENOTTY] The file associated with the fildes argument is not a master pseudo-terminal device.
At line 68225 [XSH unlockpt ERRORS], change "may fail" to "shall fail".
At line 68227 [XSH unlockpt ERRORS], change "[EINVAL]" to "[EINVAL] or [ENOTTY]".
|Tags||No tags attached.|
ttyname and ttyname_r are also affected; this would involve modifying text from 0000398:
At line 67667 [ttyname ERRORS], change "The ttyname() function may fail"
to "these functions shall fail". At line 67670, change "ttyname_r()
function may fail" to "ttyname_r() function shall fail". Then delete
lines 67671-67672, resulting in EBADF and ENOTTY as common shall fail
errors, and ERANGE as a shall fail error.
|At the Oct 3 meeting, it was requested that Eric compile a table of existing implementation behavior across all of these functions, to make it easier to see where adding new requirements is likely to make an impact.|
|2012-10-02 19:28||eblake||New Issue|
|2012-10-02 19:28||eblake||Status||New => Under Review|
|2012-10-02 19:28||eblake||Assigned To||=> ajosey|
|2012-10-02 19:28||eblake||Name||=> Eric Blake|
|2012-10-02 19:28||eblake||Organization||=> Red Hat|
|2012-10-02 19:28||eblake||User Reference||=> ebb.isatty|
|2012-10-02 19:28||eblake||Section||=> isatty|
|2012-10-02 19:28||eblake||Page Number||=> 1141|
|2012-10-02 19:28||eblake||Line Number||=> 38060|
|2012-10-02 19:28||eblake||Interp Status||=> ---|
|2012-10-02 19:32||eblake||Relationship added||child of 0000503|
|2012-10-02 19:32||eblake||Tag Attached: issue8|
|2012-10-03 03:30||eblake||Relationship added||related to 0000508|
|2012-10-03 03:30||eblake||Relationship added||child of 0000398|
|2012-10-03 03:32||eblake||Note Added: 0001386|
|2012-10-03 15:29||eblake||Note Added: 0001387|
|2019-05-23 16:09||geoffclare||Tag Detached: issue8|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|