On Fri, 2012-03-09 at 08:56 +0100, Sami Kerola wrote: > On Mon, Mar 5, 2012 at 22:51, Davidlohr Bueso <dave@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
