This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gcc cannot deal with full /tmp


On Sat, 2008-08-16 at 21:43 -0700, Zack Weinberg wrote:
> On Mon, Aug 4, 2008 at 4:02 AM, Denys Vlasenko <dvlasenk@redhat.com> wrote:
> > On Friday 01 August 2008 11:51:04 pm Zack Weinberg wrote:
> >>
> >> I'm quite confident that EEXIST and EISDIR are the only two errno
> >> codes that should trigger looping.
> >
> > I am confident that only EEXIST should trigger looping,
> > because I just tested that opening a dir with O_EXCL
> > returns EEXIST, not EISDIR.
> >
> > I will promptly change my mind as soon as I will be bitten
> > by some other Unix throwing EISDIR on me.
> >
> > Then, after a few years, when yet another Unix will also
> > bite me by throwing a ELOOP on an attempt of opening
> > a self-referential symlink in /tmp, I will add a check
> > for ELOOP too.
> >
> > And so on. EFBIG, ETXTBSY, maybe even ENODEV are in store.
> 
> The way I come to the conclusion that you should loop on EEXIST,
> EISDIR, and no others is, I assume that the open() call could produce
> _any_ code in errno.h, and then I think about what they mean.  EEXIST
> obviously describes a condition where you should loop.  So does
> EISDIR, because you could plausibly get that code just because there's
> a directory with the same name as your target file in /tmp.  (I'm
> pretty sure I've used Unices that did that.)
> 
> But none of the others you suggest could come back under normal
> operating conditions,

I disagree.

>  even if you had an OS that was insisting on
> telling you _what_ the conflicting name was by returning ELOOP for a
> bad symlink, EFBIG for a giant file because you didn't call open64()
> or whatever the official way to do that is, now -- because the only
> things that normally appear loose in /tmp are small plain files and
> directories. If you've got something exotic in /tmp with a name that
> conflicts with a compiler scratch filename, you _should_ fail the
> creation of the scratch file, because something weird is going on.

ELOOP is a good counter-example. "ln -s bogus /tmp/bogus" is not such
an implausible operation. Any user can do that.
--
vda



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]