struct dirent variances

Hello,

Recently I need to create a filesystem related code.
I noticed lot of inconsistent documentation regarding
struct dirent:

1. 'd_namlen' field
   info libc in chapter ''File System Interface"
   specifies 'd_namlen' field as length of 'd_name' string.
   When compiling under Linux (and GNU libc obviously)
   'd_namlen' is missing.

2. 'd_reclen'
   this field is documented as "length of d_name" in readdir(2) whereas in '/usr/include/dirent.h' it is described as 'size of entire directory entry'. In 'info libc' 'd_reclen' is mentioned but not really described at all.

3. 'd_off' field
   in readdir(2) this is offset to current dirent [from start of the directory], but again in '/usr/include/dirent.h' this is "offset of next directory entry".

I understand that only 'd_name' is really portable and it is enough for my purposes.
But could anybody explain above? In my opinion some of inconsistencies from 2. and 3. are due to readir(2)
possibly deals with kernel 'struct dirent' which can be independent of libc one.

Regards,
Miroslaw

Regards.

Hi,

I'm assuming you have looked at the references in the readdir manpage?

          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 */
              char           d_name[256]; /* filename */
          };

       According to POSIX, the dirent structure contains a field char d_name[] of unspecified size, with at most NAME_MAX characters preceding the terminating  null  byte.
       POSIX.1-2001 also documents the field ino_t d_ino as an XSI extension.  Use of other fields will harm the portability of your programs.

Yes, 'readdir' in 2nd chapter of man pages.

The readdir system call man page says "This is not the function you are interested in. Look at readdir(3) for the POSIX conforming C library interface. This page documents the bare kernel system call interface, which can change, and which is superseded by getdents(2)."