Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

readdir_r(3) [xfree86 man page]

READDIR_R(3)						     Linux Programmer's Manual						      READDIR_R(3)

NAME
readdir_r - read a directory SYNOPSIS
#include <dirent.h> int readdir_r(DIR *dirp, struct dirent *entry, struct dirent **result); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): readdir_r(): _POSIX_C_SOURCE || /* Glibc versions <= 2.19: */ _BSD_SOURCE || _SVID_SOURCE DESCRIPTION
This function is deprecated; use readdir(3) instead. The readdir_r() function was invented as a reentrant version of readdir(3). It reads the next directory entry from the directory stream dirp, and returns it in the caller-allocated buffer pointed to by entry. For details of the dirent structure, see readdir(3). A pointer to the returned buffer is placed in *result; if the end of the directory stream was encountered, then NULL is instead returned in *result. It is recommended that applications use readdir(3) instead of readdir_r(). Furthermore, since version 2.24, glibc deprecates readdir_r(). The reasons are as follows: * On systems where NAME_MAX is undefined, calling readdir_r() may be unsafe because the interface does not allow the caller to specify the length of the buffer used for the returned directory entry. * On some systems, readdir_r() can't read directory entries with very long names. When the glibc implementation encounters such a name, readdir_r() fails with the error ENAMETOOLONG after the final directory entry has been read. On some other systems, readdir_r() may return a success status, but the returned d_name field may not be null terminated or may be truncated. * In the current POSIX.1 specification (POSIX.1-2008), readdir(3) is not required to be thread-safe. However, in modern implementations (including the glibc implementation), concurrent calls to readdir(3) that specify different directory streams are thread-safe. There- fore, the use of readdir_r() is generally unnecessary in multithreaded programs. In cases where multiple threads must read from the same directory stream, using readdir(3) with external synchronization is still preferable to the use of readdir_r(), for the reasons given in the points above. * It is expected that a future version of POSIX.1 will make readdir_r() obsolete, and require that readdir(3) be thread-safe when concur- rently employed on different directory streams. RETURN VALUE
The readdir_r() function returns 0 on success. On error, it returns a positive error number (listed under ERRORS). If the end of the directory stream is reached, readdir_r() returns 0, and returns NULL in *result. ERRORS
EBADF Invalid directory stream descriptor dirp. ENAMETOOLONG A directory entry whose name was too long to be read was encountered. ATTRIBUTES
For an explanation of the terms used in this section, see attributes(7). +------------+---------------+---------+ |Interface | Attribute | Value | +------------+---------------+---------+ |readdir_r() | Thread safety | MT-Safe | +------------+---------------+---------+ CONFORMING TO
POSIX.1-2001, POSIX.1-2008. SEE ALSO
readdir(3) COLOPHON
This page is part of release 4.15 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/. 2016-03-01 READDIR_R(3)

Check Out this Related Man Page

READDIR(3)						     Linux Programmer's Manual							READDIR(3)

NAME
readdir, readdir_r - read a directory SYNOPSIS
#include <dirent.h> struct dirent *readdir(DIR *dirp); int readdir_r(DIR *dirp, struct dirent *entry, struct dirent **result); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): readdir_r(): _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _BSD_SOURCE || _SVID_SOURCE || _POSIX_SOURCE DESCRIPTION
The readdir() function returns a pointer to a dirent structure representing the next directory entry in the directory stream pointed to by dirp. It returns NULL on reaching the end of the directory stream or if an error occurred. On Linux, the dirent structure is defined as follows: struct dirent { ino_t d_ino; /* inode number */ off_t d_off; /* offset to the next dirent */ unsigned short d_reclen; /* length of this record */ unsigned char d_type; /* type of file; not supported by all file system types */ char d_name[256]; /* filename */ }; The only fields in the dirent structure that are mandated by POSIX.1 are: d_name[], of unspecified size, with at most NAME_MAX characters preceding the terminating null byte; and (as an XSI extension) d_ino. The other fields are unstandardized, and not present on all systems; see NOTES below for some further details. The data returned by readdir() may be overwritten by subsequent calls to readdir() for the same directory stream. The readdir_r() function is a reentrant version of readdir(). It reads the next directory entry from the directory stream dirp, and returns it in the caller-allocated buffer pointed to by entry. (See NOTES for information on allocating this buffer.) A pointer to the returned item is placed in *result; if the end of the directory stream was encountered, then NULL is instead returned in *result. RETURN VALUE
On success, readdir() returns a pointer to a dirent structure. (This structure may be statically allocated; do not attempt to free(3) it.) If the end of the directory stream is reached, NULL is returned and errno is not changed. If an error occurs, NULL is returned and errno is set appropriately. The readdir_r() function returns 0 on success. On error, it returns a positive error number (listed under ERRORS). If the end of the directory stream is reached, readdir_r() returns 0, and returns NULL in *result. ERRORS
EBADF Invalid directory stream descriptor dirp. CONFORMING TO
SVr4, 4.3BSD, POSIX.1-2001. NOTES
Only the fields d_name and d_ino are specified in POSIX.1-2001. The remaining fields are available on many, but not all systems. Under glibc, programs can check for the availability of the fields not defined in POSIX.1 by testing whether the macros _DIRENT_HAVE_D_NAMLEN, _DIRENT_HAVE_D_RECLEN, _DIRENT_HAVE_D_OFF, or _DIRENT_HAVE_D_TYPE are defined. Other than Linux, the d_type field is available mainly only on BSD systems. This field makes it possible to avoid the expense of calling lstat(2) if further actions depend on the type of the file. If the _BSD_SOURCE feature test macro is defined, then glibc defines the fol- lowing macro constants for the value returned in d_type: DT_BLK This is a block device. DT_CHR This is a character device. DT_DIR This is a directory. DT_FIFO This is a named pipe (FIFO). DT_LNK This is a symbolic link. DT_REG This is a regular file. DT_SOCK This is a Unix domain socket. DT_UNKNOWN The file type is unknown. If the file type could not be determined, the value DT_UNKNOWN is returned in d_type. Currently, only some file systems (among them: Btrfs, ext2, ext3, and ext4) have full support returning the file type in d_type. All applications must properly handle a return of DT_UNKNOWN. Since POSIX.1 does not specify the size of the d_name field, and other nonstandard fields may precede that field within the dirent struc- ture, portable applications that use readdir_r() should allocate the buffer whose address is passed in entry as follows: len = offsetof(struct dirent, d_name) + pathconf(dirpath, _PC_NAME_MAX) + 1 entryp = malloc(len); (POSIX.1 requires that d_name is the last field in a struct dirent.) SEE ALSO
getdents(2), read(2), closedir(3), dirfd(3), ftw(3), offsetof(3), opendir(3), rewinddir(3), scandir(3), seekdir(3), telldir(3), fea- ture_test_macros(7) COLOPHON
This page is part of release 3.27 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. 2010-09-10 READDIR(3)
Man Page