mktemp is dangerous, ifort

[Rudra Banerjee]

hello friends,
This is a ifort specific question.
My compilation prompts:
$ ifort -fast prime.f90
ipo: remark #11001: performing single-file optimizations
ipo: remark #11006: generating object file /tmp/ipo_ifortRlnLu5.o
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/libpthread.a(libpthread.o): In function `sem_open':
(.text+0x6858): warning: the use of `mktemp' is dangerous, better use
`mkstemp'

Is there any thing I can do with respect to mktemp and mkstemp?

[Arjen Markus]

Op woensdag 22 mei 2013 12:45:55 UTC+2 schreef Rudra Banerjee het volgende:
> hello friends,

>

>
> Is there any thing I can do with respect to mktemp and mkstemp?

Since it is coming from a library you probably do not have the sources for,
I would simply ignore this message.

Yes, there are very good reasons to use mkstemp() instead of mktemp(), but
they are related to security issues, which I doubt will be important in this
context. I bluntly assume that your application will run in a fairly typical
environment where people can generally be trusted.

Regards,

Arjen

[fj]

No !

the call to mktemp is performed in libpthread.a which is a "system" library.

Notice that this is simply a warning. I get the same one in my programs for years without trouble... But in my case, I am responsible of that because my programs actually call mktemp.

Using mkstemp is certainly safer but I was unable to call it from a FORTRAN program (mktemp, on the contrary is easy to call).

[Arjen Markus]

Op woensdag 22 mei 2013 14:37:47 UTC+2 schreef fj het volgende:

Calling it should be easy enough, but the result is a file descriptor,
which is meaningless in Fortran. You would need a way to translate the
C-style file descriptor to a Fortran-style LU-number.

Regards,

Arjen

[Tobias Burnus]

Arjen Markus wrote:
>> >Using mkstemp is certainly safer but I was unable to call it from a FORTRAN program (mktemp, on the contrary is easy to call).

> Calling it should be easy enough, but the result is a file descriptor,
> which is meaningless in Fortran. You would need a way to translate the
> C-style file descriptor to a Fortran-style LU-number.

How about:
OPEN(..., status='scratch')

That's more portable and simpler than calling mktemp manually.

In case of gfortran, it calls internally mkstemp (if available) or
mktemp. (For the latter it checks whether the file already exists and
takes care of the 26-files limit per thread (and template pattern),
which e.g. Windows' mktemp has.)

It only gets difficult if the temporary file should be kept after
exiting the program - or if the file descriptor has to be passed to a C
function. [For the latter, some compilers have a vendor intrinsic to
convert it to a descriptor, e.g. FNUM(unit).]

Tobias

[fj]

> > Using mkstemp is certainly safer but I was unable to call it from a FORTRAN program (mktemp, on the contrary is easy to call).
>
>
>
> Calling it should be easy enough, but the result is a file descriptor,
>
> which is meaningless in Fortran. You would need a way to translate the
>
> C-style file descriptor to a Fortran-style LU-number.

Yes, this is why I preferred to stick to mktemp...
>
>

>
> Regards,
>
>
>
> Arjen

[Arjen Markus]

Op woensdag 22 mei 2013 17:17:58 UTC+2 schreef Tobias Burnus het volgende:

True, but it would not help OP: the function is used in the pthread library.
So to solve it, you would need an updated version of that library. The relation
to Fortran is minimal: the Intel Fortran compiler (or better: linker) warns
about the mktemp() function being used in some function in that library.

Regards,

Arjen