This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libgfortran and libiberty: mkstemp in gfortran/io/unix.c


DJ Delorie wrote:
>>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.

I did not realize there were systems that actually had a function named
mkstemps().  I thought it was a libiberty invention.

>>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.

>From <http://www.opengroup.org/onlinepubs/009695399/functions/mkstemp.html>:
[XSI]  #include <stdlib.h>
int mkstemp(char *template);

As near as I can tell, the functions are identical in function, except
for the additional suffix semantics.  I beleive mkstemp can be
implemented like so:

int mkstemp(char *template) {
  return mkstemps(template, 0);
}

> Assuming you can rely on libiberty being linked.  Can libgfortran
> depend on libiberty being linked also?  Or must libgfortran be
> stand-alone?

I don't know.  Does someone know?


Aaron W. LaFramboise


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]