linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Paul Eggert <eggert-764C0pRuGfqVc3sceRu5cw@public.gmane.org>,
	Siddhesh Poyarekar
	<siddhesh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	Rich Felker <dalias-/miJ2pyFWUyWIDz0JBNUog@public.gmane.org>,
	Carlos O'Donell <carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	KOSAKI Motohiro
	<kosaki.motohiro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	libc-alpha <libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org>,
	Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org>,
	linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] Fix readdir_r with long file names
Date: Wed, 2 Mar 2016 11:39:06 +0100	[thread overview]
Message-ID: <56D6C2CA.2020609@gmail.com> (raw)
In-Reply-To: <56D6294A.5040703-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

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/
--
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

  parent reply	other threads:[~2016-03-02 10:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <51B0B39F.4060202@redhat.com>
     [not found] ` <51B0BD36.3030202@redhat.com>
     [not found]   ` <CAHGf_=r9Rz63pho+84ORk0a_oDyJSj-MCnZ56uPrT3L6sVEfeQ@mail.gmail.com>
     [not found]     ` <20130607013024.GO29800@brightrain.aerifal.cx>
     [not found]       ` <51B19203.3070307@redhat.com>
     [not found]         ` <20130607144143.GQ29800@brightrain.aerifal.cx>
     [not found]           ` <51B57E35.4080403@redhat.com>
     [not found]             ` <51B65EA7.2020402@redhat.com>
     [not found]               ` <20130611011324.GT29800@brightrain.aerifal.cx>
     [not found]                 ` <51B8702D.2060505@redhat.com>
     [not found]                   ` <20130813040038.GE21795@spoyarek.pnq.redhat.com>
     [not found]                     ` <520C88A6.9070501@redhat.com>
     [not found]                       ` <520C88A6.9070501-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-01  8:07                         ` [PATCH] Fix readdir_r with long file names Michael Kerrisk (man-pages)
2016-03-01 16:59                           ` Florian Weimer
     [not found]                             ` <56D5CA79.9030204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-01 20:14                               ` Michael Kerrisk (man-pages)
     [not found]                                 ` <56D5F832.3070209-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-01 20:27                                   ` Florian Weimer
     [not found]                                     ` <56D5FB3D.5000306-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-01 21:01                                       ` Michael Kerrisk (man-pages)
     [not found]                                         ` <56D60335.7010906-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-01 22:21                                           ` Florian Weimer
     [not found]                                             ` <56D615D7.5020304-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-01 22:27                                               ` Rich Felker
2016-03-02  8:17                                               ` Michael Kerrisk (man-pages)
2016-03-01 21:20                                     ` Paul Eggert
     [not found]                                       ` <56D607BB.6080701-764C0pRuGfqVc3sceRu5cw@public.gmane.org>
2016-03-01 22:16                                         ` Florian Weimer
2016-03-01 22:41                                           ` Paul Eggert
     [not found]                                             ` <56D61A86.3050108-764C0pRuGfqVc3sceRu5cw@public.gmane.org>
2016-03-01 23:07                                               ` Florian Weimer
     [not found]                                                 ` <56D620AA.40108-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-01 23:25                                                   ` Paul Eggert
     [not found]                                                     ` <56D624FE.1090702-764C0pRuGfqVc3sceRu5cw@public.gmane.org>
2016-03-01 23:44                                                       ` Florian Weimer
     [not found]                                                         ` <56D6294A.5040703-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-02 10:39                                                           ` Michael Kerrisk (man-pages) [this message]
     [not found]                                                             ` <56D6C2CA.2020609-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-08 17:20                                                               ` Michael Kerrisk (man-pages)
2016-03-10 11:22                                                             ` Florian Weimer
     [not found]                                                               ` <56E158F4.6040506-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-10 17:06                                                                 ` Michael Kerrisk (man-pages)
2016-03-02 17:44                                                         ` Paul Eggert
     [not found]                                                           ` <56D72683.6010302-764C0pRuGfqVc3sceRu5cw@public.gmane.org>
2016-03-03 22:39                                                             ` Joseph Myers
2016-03-08 12:20                                                             ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56D6C2CA.2020609@gmail.com \
    --to=mtk.manpages-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=dalias-/miJ2pyFWUyWIDz0JBNUog@public.gmane.org \
    --cc=eggert-764C0pRuGfqVc3sceRu5cw@public.gmane.org \
    --cc=fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=kosaki.motohiro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org \
    --cc=siddhesh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).