bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal: module 'mkostemp'


From: Bruno Haible
Subject: Re: proposal: module 'mkostemp'
Date: Sun, 23 Aug 2009 11:24:39 +0200
User-agent: KMail/1.9.9

Eric Blake wrote:
> Nice to do some resyncing.  Overall, I'm in favor of this improvement.

I also wait for Jim's opinion.

> > /* Generate a unique temporary file name from TEMPLATE.
> >    The last six characters of TEMPLATE must be "XXXXXX";
> >    they are replaced with a string that makes the file name unique.
> >    Then open the file and return a fd. */
> > int
> > mkostemp (template, flags)
> >      char *template;
> >      int flags;
> 
> I take it the failure to mention 'flags' in the comment is a glibc oversight?

Yes.

> > +#if @GNULIB_MKOSTEMP@
> > +# if address@hidden@
> > +/* Create a unique temporary file from TEMPLATE.
> > +   The last six characters of TEMPLATE must be "XXXXXX";
> > +   they are replaced with a string that makes the file name unique.
> > +   The file is then created, with the specified flags, ensuring it didn't 
> > exist
> > +   before.
> 
> Should we mention which FLAGS are portable in the gnulib version
> (O_CLOEXEC, O_BINARY, O_TEXT), as you did for accept4?

Yes, I'm adding the same description.

> > -     fd = large_open (tmpl, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);
> > +     fd = __open (tmpl,
> > +                  (flags & ~0777) | O_RDWR | O_CREAT | O_EXCL,
> > +                  S_IRUSR | S_IWUSR);
> 
> Wow - that means any other flags larger than 9  bits, like the sticky bits
> at 07000, or even implementation-specific O_* values, are blindly passed
> through.  Do we really want that?

Yes, why not? There are numerous ways to shoot yourself in the foot. If glibc
does not limit the flags to a specific set, why should we?

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]