Re: [PATCH 09/17] lib: add fileutils function collection

[Davidlohr Bueso <dave@gnu.org>]

On Fri, 2012-03-09 at 08:56 +0100, Sami Kerola wrote:
> On Mon, Mar 5, 2012 at 22:51, Davidlohr Bueso <dave@gnu.org> wrote:
> > On Mon, 2012-03-05 at 20:38 +0100, Sami Kerola wrote:
> >>  create mode 100644 include/fileutils.h
> >>  create mode 100644 lib/fileutils.c
> >
> > Doesn't really make much sense creating two files for just one
> > function.  Couldn't xmkstemp() so somewhere else?  You might argue
> > that xgetpass also does that, I just think it's an overkill...
> 
> Hi Davidlohr,
> 
> You are right, at least partially.  The reason why I added the files
> is simply that non of the existing files felt correct to add this
> function.  IMHO xgetpass.c would be more strange file to have
> xmkstemp() than fileutils.c to contain xgetpass().

I'm just saying that xgetpass also just contains one function and that
it's an overkill, no big deal in any case.

> 
> >> +/* Create open temporary file in safe way.  Please notice that the
> >> + * file permissions are -rw------- by default. */
> >> +FILE *xmkstemp(char **tmpname)
> >
> > Returning the file descriptor seems a more flexible interface
> > instead of the FILE's representation; the user can always use
> > fdopen on his own.
> 
> If I need temporary file I rather have stream than file descriptor.
> Could you give example why flexibility is better than completeness.
> With completeness I mean service that the function provides.  If
> after every single occurrence of xmkstemp() there would be fdopen() I
> would argue adding flexibility did not do anything good.

I don't see how streams are more complete than descriptors - and no,
every call to mkstemp *does not* require a call to fdopen, that's
completely up to the user's use case.

Cheers,
Davidlohr