|TTYNAME(3C)||Standard C Library Functions||TTYNAME(3C)|
#include <unistd.h> char *ttyname(int fildes);
char *ttyname_r(int fildes, char *name, int namelen);
cc [ flag...] file ... -D_POSIX_PTHREAD_SEMANTICS [ library ... ] int ttyname_r(int fildes, char *name, size_t namesize);
The ttyname() function returns a pointer to a string containing the null-terminated path name of the terminal device associated with file descriptor fildes. The return value points to thread-specific data whose content is overwritten by each call from the same thread.
The ttyname_r() function has the same functionality as ttyname() except that the caller must supply a buffer name with length namelen to store the result; this buffer must be at least _POSIX_PATH_MAX in size (defined in <limits.h>). The standard-conforming version (see standards(5)) of ttyname_r() takes a namesize parameter of type size_t.
Upon successful completion, ttyname() and ttyname_r() return a pointer to a string. Otherwise, a null pointer is returned and errno is set to indicate the error.
The standard-conforming ttyname_r() returns 0 if successful or the error number upon failure.
The ttyname() and ttyname_r() functions may fail if:
The ttyname_r() function may fail if:
See attributes(5) for descriptions of the following attributes:
|ATTRIBUTE TYPE||ATTRIBUTE VALUE|
When compiling multithreaded applications, see Intro(3), Notes On Multithreaded Applications.
Messages printed from this function are in the native language specified by the LC_MESSAGES locale category. See setlocale(3C).
The return value of ttyname() points to thread-specific data whose content is overwritten by each call from the same thread. This function is safe to use in multithreaded applications, but its use is discouraged. The ttyname_r() function should used instead.
Solaris 2.4 and earlier releases provided definitions of the ttyname_r() interface as specified in POSIX.1c Draft 6. The final POSIX.1c standard changed the interface as described above. Support for the Draft 6 interface is provided for compatibility only and might not be supported in future releases. New applications and libraries should use the standard-conforming interface.
|March 31, 2005||OmniOS|