This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: libgfortran and libiberty: mkstemp in gfortran/io/unix.c
- From: DJ Delorie <dj at redhat dot com>
- To: aaronavay62 at aaronwl dot com
- Cc: gcc at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Wed, 15 Sep 2004 19:48:26 -0400
- Subject: Re: libgfortran and libiberty: mkstemp in gfortran/io/unix.c
- References: <4148C684.7060900@aaronwl.com>
> However, there doesn't appear to be a prototype anywhere for it, but
> I think it should, since it is not a replacement function (...is
> it?).
Read the documentation!
@deftypefn Replacement int mkstemps (char *@var{template}, int @var{suffix_len})
> Should a prototype be added to include/libiberty.h for it?
No.
> And, should unix.c be using it instead of mkstemp, which libiberty does
> not seem to provide? Or maybe libiberty should provide a mkstemp?
mkstemps returns a file handle, mkstemp returns a name. They're not
interchangeable, and you can't use mkstemps to create a directory.
But mkstemps is more secure if you can use it.
mkstemp wouldn't be in libiberty if there was no platform we supported
that didn't have it. If you find one (which apparently you did)
... patches welcome ;-)
Assuming you can rely on libiberty being linked. Can libgfortran
depend on libiberty being linked also? Or must libgfortran be
stand-alone?