#include <dirent.h> struct dirent *readdir(DIR *dirp);
Dans l'implémentation de la glibc, la structure dirent est définie comme suit :
struct dirent {
ino_t d_ino; /* numéro d'inœud */
off_t d_off; /* pas une position ; consultez NOTES */
unsigned short d_reclen; /* longueur de cet enregistrement */
unsigned char d_type; /* type du fichier ; pas pris en
charge par tous les types de
système de fichiers */
char d_name[256]; /* nom du fichier terminé par l'octet NULL */
};
Les seuls champs exigés par POSIX.1 pour la structure dirent sont d_name et d_ino. Les autres champs ne sont pas normalisés et ne sont pas présents sur tous les systèmes ; consultez les NOTES ci-dessous pour plus de détails.
Les champs de la structure dirent sont les suivants :
Les données renvoyées par readdir() sont écrasées lors de l'appel suivant à readdir() sur le même flux répertoire.
Lorsque la fin du flux répertoire est atteinte, NULL est renvoyé et errno n'est pas modifiée. En cas d'erreur, NULL est renvoyée et errno contient le code d'erreur. Pour distinguer la fin du flux d'une erreur, il faut assigner errno à zéro avant d'appeler readdir() puis ensuite tester la valeur de errno si NULL est renvoyé.
| Interface | Attribut | Valeur |
| readdir() | Sécurité des threads | MT-Unsafe race:dirstream |
Dans la spécification POSIX.1 courante (POSIX.1-2008), il n'est pas requis que readdir(3) soit sûr vis-à-vis des threads. Cependant, dans les implémentations modernes, incluant la glibc, des appels concurrents à readdir(3) pour des flux répertoire différents sont sûrs vis-à-vis des threads. Dans le cas où de multiples threads doivent lire depuis un flux de répertoire identique, l'utilisation de readdir(3) avec une synchronisation externe est toujours préférable à l'utilisation de readdir_r(3). Il est attendu qu’une future version de POSIX.1 demande que readdir() soit sûr vis-à-vis des threads lorsqu’il est employé simultanément sur des flux répertoire différents.
L'ordre dans lequel les noms de fichier sont lus par des appels successifs à readdir() dépend de l'implémentation du système de fichiers ; il est peu probable que les noms soient triés d'une quelconque façon.
Seuls les champs d_name et (comme extension XSI) d_ino sont spécifiés dans POSIX.1. Ailleurs que sur Linux, le champ d_type est principalement disponible sur les systèmes BSD. Les autres champs sont disponibles sur beaucoup de systèmes, mais pas sur tous. Avec la glibc, les programmes peuvent vérifier la disponibilité des champs non définis dans POSIX.1 en testant si les macros _DIRENT_HAVE_D_NAMLEN, _DIRENT_HAVE_D_RECLEN, _DIRENT_HAVE_D_OFF ou _DIRENT_HAVE_D_TYPE sont définies.
Avertissement : les applications devraient éviter tout dépendance sur la taille du champ d_name. POSIX la définit comme char d_name[], un tableau de caractères de taille non spécifiée, avec au plus NAME_MAX caractères avant l'octet NULL final ('\0').
POSIX.1 est explicite sur le fait que ce champ ne doit pas être utilisé comme une lvalue. La norme ajoute que l'utilisation de sizeof(d_name) est incorrecte ; utilisez strlen(d_name) à la place. Sur certains systèmes, ce champ est défini comme char~d_name[1] ! Cela implique que l'utilisation de sizeof(struct dirent) pour déterminer la taille de l'enregistrement, y compris du champ d_name, est également incorrecte.
Notez que bien que l'appel
fpathconf(fd, _PC_NAME_MAX)
renvoie la valeur 255 pour la plupart des systèmes de fichiers, le nom de fichier terminé par l'octet NULL qui est (correctement) renvoyé dans d_name peut en fait dépasser cette taille sur certains systèmes de fichiers (CIFS ou les serveurs Windows SMB par exemple). Dans de tels cas, le champ d_reclen contiendra une valeur qui dépasse la taille de la structure dirent de la glibc montrée plus haut.
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à