From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael Kerrisk (man-pages)" Subject: Re: [PATCH] Fix readdir_r with long file names Date: Tue, 8 Mar 2016 18:20:25 +0100 Message-ID: <56DF09D9.3050909@gmail.com> References: <51B0B39F.4060202@redhat.com> <51B0BD36.3030202@redhat.com> <20130607013024.GO29800@brightrain.aerifal.cx> <51B19203.3070307@redhat.com> <20130607144143.GQ29800@brightrain.aerifal.cx> <51B57E35.4080403@redhat.com> <51B65EA7.2020402@redhat.com> <20130611011324.GT29800@brightrain.aerifal.cx> <51B8702D.2060505@redhat.com> <20130813040038.GE21795@spoyarek.pnq.redhat.com> <520C88A6.9070501@redhat.com> <56D54DAD.1040306@gmail.com> <56D5CA79.9030204@redhat.com> <56D5F832.3070209@gmail.com> <56D5FB3D.5000306@redhat.com> <56D607BB.6080701@cs.ucla.edu> <56D614AA.7020500@redhat.com> <56D61A86.3050108@cs.ucla.edu> <56D620AA.40108@redhat.com> <56D624FE.1090702@cs.ucla.edu> <56D6294A.5040703@redhat.com> <56D6C2CA.2020609@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <56D6C2CA.2020609-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Florian Weimer , Paul Eggert , Siddhesh Poyarekar Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Rich Felker , Carlos O'Donell , KOSAKI Motohiro , libc-alpha , Roland McGrath , linux-man List-Id: linux-man@vger.kernel.org Ping on this man page text. Anyone have an opinion for or against? Thanks, Michael On 03/02/2016 11:39 AM, Michael Kerrisk (man-pages) wrote: > 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 alread= y, so >>> this isn't that worrisome. >> >> Just to be clear, you looked at the wrong struct dirent definition f= or >> 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 appear= s 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 dir= ent >> declarators as well. >=20 > So, it seems like much more could be said about this in documentation= =2E > How about the following text for the man page? >=20 > DESCRIPTION >=20 > [...] >=20 > In the glibc implementation, the dirent structure is defined a= s > follows: >=20 > struct dirent { > ino_t d_ino; /* Inode number */ > off_t d_off; /* Not an offset; see belo= w */ > unsigned short d_reclen; /* Length of this record *= / > unsigned char d_type; /* Type of file; not suppo= rted > by all filesystem types= */ > char d_name[256]; /* Null-terminated filenam= e */ > }; >=20 > [...] > NOTES > The d_name field > The dirent structure definition shown above is taken from th= e > glibc headers, and shows the d_name field with a fixed size. >=20 > Warning: applications should avoid any dependence on the siz= e > of the dname field. POSIX defines it as char d_name[], a char= =E2=80=90 > acter array of unspecified size, with at most NAME_MAX charac= =E2=80=90 > ters preceding the terminating null byte ('\0'). >=20 > POSIX.1 explicitly notes that this field should not be used a= s > an lvalue. The standard also notes that the use o= f > sizeof(d_name) (and by implication sizeof(struct dirent)) i= s > incorrect; use strlen(d_name) instead. (On some systems, thi= s > field is defined as char d_name[1]!) >=20 > Note that while the call >=20 > fpathconf(fd, _PC_NAME_MAX) >=20 > returns the value 255 for most filesystems, on some filesystem= s > (e.g., CIFS, Windows SMB servers), the null-terminated filenam= e > that is (correctly) returned in d_name can actually exceed thi= s > size. (In such cases, the d_reclen field will contain a valu= e > that exceeds the size of the glibc dirent structure show= n > above.) >=20 > Cheers, >=20 > Michael >=20 --=20 Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html