Austin Group Defect Tracker

Aardvark Mark IV

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
0000618 [1003.1(2008)/Issue 7] System Interfaces Objection Error 2012-10-02 19:28 2024-06-11 14:01
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Eric Blake
Organization Red Hat
User Reference ebb.isatty
Section isatty
Page Number 1141
Line Number 38060
Interp Status ---
Final Accepted Text
Summary 0000618: require isatty and friends to set errno on failure
Description 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.
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.
Attached Files

- Relationships
related to 0000508Closedajosey Add ptsname_r 
child of 0000503Closedajosey ptsname should define optional errno values 
child of 0000398Closedajosey mandatory ERANGE failures on insufficient buffer size 

-  Notes
(0001386)
eblake (manager)
2012-10-03 03:32

 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.
(0001387)
eblake (manager)
2012-10-03 15:29

 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.
(0006810)
eblake (manager)
2024-06-11 14:01

 Locally running a program derived from 0000503 as a starting point, I can report:

Linux 6.8.11 on x86_64
$ ./a.out
25 Inappropriate ioctl for device
22 Invalid argument
22 Invalid argument


With some help from Collin Funk utilizing the GNU compiler farm (https://sourceware.org/pipermail/libc-alpha/2024-June/157327.html), [^] I've collected a lot more system behaviors:

AIX 7.1.1 (cfarm111):
$ ./a.out
25 Not a typewriter
25 Not a typewriter
22 Invalid argument

Oracle Solaris 11.3 (cfarm211):
$ ./a.out
25 Inappropriate ioctl for device
25 Inappropriate ioctl for device
25 Inappropriate ioctl for device

OpenBSD 7.5 (cfarm220):
$ ./a.out
22 Invalid argument
22 Invalid argument
22 Invalid argument

FreeBSD 14.0 (cfarm240):
$ ./a.out
22 Invalid argument
22 Invalid argument
22 Invalid argument

Alpine 3.19 w/ Musl (cfarm27):
$ ./a.out
25 Not a tty
25 Not a tty
0 No error information

MacOS 12.6 (cfarm104):
$ ./a.out
25 Inappropriate ioctl for device
25 Inappropriate ioctl for device
25 Inappropriate ioctl for device

A NetBSD 10.0 virtual machine:
$ ./a.out
25 Inappropriate ioctl for device
0 Undefined error: 0
25 Inappropriate ioctl for device


Plus some other non-public reporting from Tim Rice:

UnixWare 7.1.4
root@tim161 # uname -a
UnixWare tim161 5 7.1.4 i386 x86at SCO UNIX_SVR5
root@tim161 # ./a.out
25 Not a typewriter
25 Not a typewriter
0 Error 0
root@tim161 #

OpenServer 6
tim@osr6 5% uname -a
SCO_SV osr6 5 6.0.0 i386
tim@osr6 6% ./a.out
25 Not a typewriter
25 Not a typewriter
0 Error 0
tim@osr6 7%

OpenServer 5
tim(tim)@timosr5d 3% uname -a
SCO_SV timosr5d 3.2 5.0.7 i386
tim(tim)@timosr5d 4% ./a.out
25 Inappropriate I/O control operation
25 Inappropriate I/O control operation
25 Inappropriate I/O control operation


It looks like all of these systems use 25 for ENOTTY and 22 for EINVAL (although this particular mapping is not required by POSIX)

- Issue History
Date Modified Username Field Change
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
2024-06-11 14:01 eblake Note Added: 0006810

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker