tmpfile-gnu: yes!

[Jim Meyering]

Eric Blake wrote:
...
> This is a proof-of-concept patch; it solves the problem at hand,
> but has some dependencies on incompatible modules that would
> need to be relaxed to LGPLv2+ before this module could be used
> in libvirt.
>
...
> Do we want a tmpfile-gnu module that guarantees that tmpfile() is
> not constrained by silly platform limits, and does not put garbage
> on stderr on failure to create a temporary file?

That sounds worthwhile.
No one wants their daemon or library code to spew diagnostics to stderr.

[of course, this assumes that the developers in question
 are already resigned to using streams ;-) ]

An alternative would be to use the combination of mkstemp and fdopen directly.
However, mkstemp's documented portability/security risk
  http://git.sv.gnu.org/cgit/gnulib.git/plain/doc/posix-functions/mkstemp.texi
is an obstacle, since the solution is to set the umask, and that is
library-unfriendly.  Consolation: it's needed only on non-glibc systems.

...
> +/* Heavyweight implementation that requires a temporary file as
> +   backing store.  Relies on an override to fflush() to keep things in
> +   sync, and an override to fclose() to clean up memory.  */
> +FILE *
> +open_memstream (char **buf, size_t *len)
> +{
> +  /* FIXME: tmpfile is allowed to write to stderr on failure - are we
> +     happy with that?  */
> +  FILE *f = tmpfile ();