This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix readdir_r with long file names
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: mtk dot manpages at gmail dot com, Rich Felker <dalias at aerifal dot cx>, Carlos O'Donell <carlos at redhat dot com>, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, linux-man <linux-man at vger dot kernel dot org>
- Date: Wed, 2 Mar 2016 11:39:06 +0100
- Subject: Re: [PATCH] Fix readdir_r with long file names
- Authentication-results: sourceware.org; auth=none
- References: <51B0B39F dot 4060202 at redhat dot com> <51B0BD36 dot 3030202 at redhat dot com> <CAHGf_=r9Rz63pho+84ORk0a_oDyJSj-MCnZ56uPrT3L6sVEfeQ at mail dot gmail dot com> <20130607013024 dot GO29800 at brightrain dot aerifal dot cx> <51B19203 dot 3070307 at redhat dot com> <20130607144143 dot GQ29800 at brightrain dot aerifal dot cx> <51B57E35 dot 4080403 at redhat dot com> <51B65EA7 dot 2020402 at redhat dot com> <20130611011324 dot GT29800 at brightrain dot aerifal dot cx> <51B8702D dot 2060505 at redhat dot com> <20130813040038 dot GE21795 at spoyarek dot pnq dot redhat dot com> <520C88A6 dot 9070501 at redhat dot com> <56D54DAD dot 1040306 at gmail dot com> <56D5CA79 dot 9030204 at redhat dot com> <56D5F832 dot 3070209 at gmail dot com> <56D5FB3D dot 5000306 at redhat dot com> <56D607BB dot 6080701 at cs dot ucla dot edu> <56D614AA dot 7020500 at redhat dot com> <56D61A86 dot 3050108 at cs dot ucla dot edu> <56D620AA dot 40108 at redhat dot com> <56D624FE dot 1090702 at cs dot ucla dot edu> <56D6294A dot 5040703 at redhat dot com>
On 03/02/2016 12:44 AM, Florian Weimer wrote:
> On 03/02/2016 12:25 AM, Paul Eggert wrote:
>
>>> And at the cost of
>>> changing sizeof (struct dirent), which can't be a good thing.
>>
>> Any program that depends on sizeof (struct dirent) is broken already, so
>> this isn't that worrisome.
>
> Just to be clear, you looked at the wrong struct dirent definition for
> GNU/Linux, there is a sysdeps override.
>
> Right now, most programs relying on sizeof (struct dirent) work well in
> almost all cases. We really don't want to break that. There appears to
> be an overlap between these programs and users of readdir_r, so once we
> remove that from the API, we should have better story for struct dirent
> declarators as well.
So, it seems like much more could be said about this in documentation.
How about the following text for the man page?
DESCRIPTION
[...]
In the glibc implementation, the dirent structure is defined as
follows:
struct dirent {
ino_t d_ino; /* Inode number */
off_t d_off; /* Not an offset; see below */
unsigned short d_reclen; /* Length of this record */
unsigned char d_type; /* Type of file; not supported
by all filesystem types */
char d_name[256]; /* Null-terminated filename */
};
[...]
NOTES
The d_name field
The dirent structure definition shown above is taken from the
glibc headers, and shows the d_name field with a fixed size.
Warning: applications should avoid any dependence on the size
of the dname field. POSIX defines it as char d_name[], a charâ
acter array of unspecified size, with at most NAME_MAX characâ
ters preceding the terminating null byte ('\0').
POSIX.1 explicitly notes that this field should not be used as
an lvalue. The standard also notes that the use of
sizeof(d_name) (and by implication sizeof(struct dirent)) is
incorrect; use strlen(d_name) instead. (On some systems, this
field is defined as char d_name[1]!)
Note that while the call
fpathconf(fd, _PC_NAME_MAX)
returns the value 255 for most filesystems, on some filesystems
(e.g., CIFS, Windows SMB servers), the null-terminated filename
that is (correctly) returned in d_name can actually exceed this
size. (In such cases, the d_reclen field will contain a value
that exceeds the size of the glibc dirent structure shown
above.)
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/