linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Paul Eggert <eggert-764C0pRuGfqVc3sceRu5cw@public.gmane.org>,
	"Michael Kerrisk (man-pages)"
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Siddhesh Poyarekar
	<siddhesh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: 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 00:07:22 +0100	[thread overview]
Message-ID: <56D620AA.40108@redhat.com> (raw)
In-Reply-To: <56D61A86.3050108-764C0pRuGfqVc3sceRu5cw@public.gmane.org>

On 03/01/2016 11:41 PM, Paul Eggert wrote:
> On 03/01/2016 02:16 PM, Florian Weimer wrote:
>>> Why not use a flexible array member for this?
>> For which part, and how exactly?
> 
> Something like the attached patch, say.  (Totally untested.)
> 
>> You can't put a flexible array member into a transparent union.
> 
> That's OK. Any such usage of struct dirent would be unportable anyway.
> 
>> If you mean to add some zero-width padding member at the end of the
>> struct, after the d_name member, then I'm worried that makes overrunning
>> the d_name array member even more undefined than it already is.
> 
> No, no padding member, just use C99 the way it was designed.  This
> should improve overrun detection in programs like valgrind. With glibc's
> current definition these programs can be fooled into thinking that
> struct dirent accesses are invalid (outside of array bounds) when they
> are actually OK, so people shut off array-bounds checking. If we used
> flexible array members, valgrind etc. should know that the array's upper
> bound is unknown and should not issue so many false alarms, so people
> can leave bounds checking on.

I don't think valgrind can see the difference, but you are correct in
principle (this is essentially the “undefined” part I was worried about).

Unfortunately, GCC does not produce a warning for taking the size of a
struct with a flexible member, or for using it in a non-pointer
declarator, so it does only half of what we want.  And at the cost of
changing sizeof (struct dirent), which can't be a good thing.

> If flexible arrays are no-go for some reason, I suppose we could use
> 'char 'd_name[SIZE_MAX - 1000];' instead. That should get peoples'
> attention. :-)

GCC refuses to compile the type definition, not just declarations.
Refusing declarations with an error would break quite a lot of existing
configure tests.

  struct dirent d; int z; z - d.d_ino;

is a common idiom to check for struct members.

Florian
--
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-01 23:07 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 [this message]
     [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)
     [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=56D620AA.40108@redhat.com \
    --to=fweimer-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=dalias-/miJ2pyFWUyWIDz0JBNUog@public.gmane.org \
    --cc=eggert-764C0pRuGfqVc3sceRu5cw@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=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@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).