Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eliminate use of mktemp -- use mkstemp instead #43

Closed
wants to merge 27 commits into from

Conversation

gsjaardema
Copy link
Contributor

The use of mktemp() results in an unsuppressable warning message
on certain compilers, including gcc. This causes problems for
projects which have rules regarding warning-free compiles.

Use mkstemp instead. The problem with mkstemp is that it opens the
file instead of just returning a unique file name. However, as a
side effect it does change the template to a unique file name.
This can be used similarly to the return value from mktemp.

gsjaardema and others added 25 commits January 13, 2016 11:44
The use of mktemp() results in an unsuppressable warning message
on certain compilers, including gcc.  This causes problems for
projects which have rules regarding warning-free compiles.

Use mkstemp instead. The problem with mkstemp is that it opens the
file instead of just returning a unique file name.  However, as a
side effect it does change the template to a unique file name.
This can be used similarly to the return value from mktemp.
@tbeu
Copy link
Owner

tbeu commented Aug 24, 2016

Why not stay with mktemp on MSVC as e.g. here: tkelman/graphviz@acdbce8 ?

@gsjaardema
Copy link
Contributor Author

That is a valid alternative. To my eye, it dirties up the actual source code more with all the ifdefs in the code versus an ifdef up at the top in the "preamble" code.

Perhaps a better fix than either would be to encapsulate the mkstemp/mktemp changes in a static function. The function would return the filename that should be used in the Mat_CreateVer call. This would hide all ifdefs at the top and eliminate confusion as to why mkstemp() was being used just for the side-effect of changing the filename template.

@@ -883,7 +885,8 @@ Mat_VarDelete(mat_t *mat, const char *name)
break;
}

tmp = Mat_CreateVer(tmp_name,mat->header,mat_file_ver);
close(fd);
tmp = Mat_CreateVer(temp,mat->header,mat_file_ver);
Copy link
Owner

@tbeu tbeu Aug 24, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This introduces a race condition: After closing the file descriptor fd of the temporary file temp might no longer be a unique temporary filename. Thus a proper fix also requires replacing all fwrite calls by write (which is some effort and modifies/adds the API functions like Mat_CreateVer).

int fd = mkstemp(temp);
if (fd > 0) {
close(fd);
return temp;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This introduces a race condition: After closing the file descriptor fd of the temporary file temp might no longer be a unique temporary filename. Thus a proper fix also requires replacing all fwrite calls by write (which is some effort and changes the existing API functions like Mat_CreateVer).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, but I guess I was going for good enough vs perfect. The current pull request eliminates the compiler warnings from mktemp and is at least as good with regards to security and race conditions.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this is an old issue: https://sourceforge.net/p/matio/bugs/10/
I already considered to fix it but want to do it the perfect way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure that the fwrite vs write is the perfect fix either since I don't think it will work with the hdf5-based file formats will it?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just saw http://stackoverflow.com/q/1941464. ANSI C compatibility also is important (as I was told at https://trac.modelica.org/Modelica/ticket/1258).

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 62ed547 on gsjaardema:master into * on tbeu:master*.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling c1e5cb6 on gsjaardema:master into * on tbeu:master*.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 62ed547 on gsjaardema:master into * on tbeu:master*.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 62ed547 on gsjaardema:master into * on tbeu:master*.

@tbeu tbeu force-pushed the master branch 4 times, most recently from 68de3b3 to 887adee Compare January 26, 2017 08:08
@tbeu tbeu added the wontfix label Jan 26, 2017
@tbeu
Copy link
Owner

tbeu commented Jan 26, 2017

Without the dependency on the hdf5 library I figured out a secure temp file creation in Mat_VarDelete using tmpfile (and thus avoiding the file name argument). However, as long as the hdf5 library does not support any secure temp file creation and management, I will not touch it. (HDF5 issue number is HDFFV-8703 from 2014.)

So, for now, I close this with wontfix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants