On 06/22/2017 09:12 AM, Patrick Alken wrote: > In GSL 2.3 and earlier, the vector and matrix modules tested the > fwrite/fread routines by creating temporary files with mkstemp() and > fdopen(). Unfortunately neither of these routines conform to the ANSI > C89 standard and so I converted these tests to write to a fixed filename > "test.dat". However this caused the file race condition which was > reported in the recent test candidates (i.e. the "make check -j8" > error). So finally I switched to use tmpfile() which is C89 and seems to > be the only ANSI-compatible method of using temporary files in C. But > now it seems that some windows systems fail with this method due to > permission restrictions. > > I can certainly modify the tests to check for a NULL pointer coming out > of tmpfile, but this would then disable these tests on your windows > systems, which is not ideal either. It appears we must either accept > that the matrix/vector fread/fwrite routines cannot be properly tested > on windows systems, or go back to a non-ANSI method of writing the > temporary files. Neither of these choices seem good to me, but my > preference would be to follow the C89 standard if possible. > > I thought about writing a routine inside GSL to perform the same task as > mkstemp() does, but it seems this is not possible in C89 since mkstemp > relies on calling open() with O_EXCL to raise an error if the file > already exists, but open() is also not C89. > > I am open to suggestions if anyone knows of a solution to this problem.
Hello, what is wrong about using tmpnam + fopen ? See "Remarks" section in https://msdn.microsoft.com/en-us/library/x8x7sakw.aspx It should solve the problem with placing the file in other path than root directory. According to linux manpages, both tmpnam and fopen should be C89 compatible. https://msdn.microsoft.com/de-de/subscriptions/hs3e7355(v=vs.80).aspx states it is ANSI compatible implementation available since Windows 95. David > > Patrick > > On 06/21/2017 03:26 PM, Max Gaspa wrote: >> Dear all, >> >> Sisyphus wrote >> >>> Much the same situation here - Windows 7 64 bit, mingw-w64 port of 64-bit >>> gcc-6.3.0 (x86_64-posix-sjlj-rev1). >>> And, like you (apparently), I didn't test the release candidates :-( >> Yes. And Yes. I didn't check the release candidate because the short >> time between the availability of the RC and the availability of the >> official release. >> >> >> Anyway I think I found the reason of the issue just following the >> program flow with gdb. The issue is NOT related to malloc(0) (I' still >> thinking that is not a good programming practice but I will accept it >> :-) ) >> >> I'm discussing the issue for vector just to describe it in a simpler way. >> >> The reason of the segmentation fault is the latest modification made >> by Patrick 7 days ago into test_source.c ( described by "fix file >> race condition for 'make check -j8'" ). >> >> The lines involved are >> >> - char filename[] = "test.dat"; >> + FILE *f = tmpfile(); >> >> in few words the change imply using tmpfile(). Unfortunately in >> Windows (XP is fine! 7 fails) that call is creating a temporary file >> in C:\ that is usually not writable for security reason. The call >> fails and the pointer f is NULL. Because there are no checking for >> NULL after the call to tmpfile() (It seems GSL developer love not >> checking for null pointer!!!! :-) :-) :-) ) and the next call to >> fprintf will use NULL as its stream you get the segmentation fault. >> >> Now I'm trying to revert the change (just using the release candidate >> version should be fine) to see if the issue is fixed, but I'm quite >> sure because gdb told me that f was NULL but it was used as a valid >> pointer for the stream >> >> For reference: >> >> Microsoft documentation of the C runtime library (used by MinGW) for >> tmpfile() >> >> ******* >> The tmpfile() function creates a temporary file and returns a pointer >> to that stream. The temporary file is created in the root directory. >> To create a temporary file in a directory other than the root, use >> tmpnam or tempnam in conjunction with fopen. >> >> If the file cannot be opened, tmpfile returns a NULL pointer. This >> temporary file is automatically deleted when the file is closed, when >> the program terminates normally, or when _rmtmp is called, assuming >> that the current working directory does not change. The temporary file >> is opened in w+b (binary read/write) mode. >> >> Failure can occur if you attempt more than TMP_MAX (see STDIO.H) calls >> with tmpfile. >> >> ********* >> >> I'm also observing the error related to the Bessel function like you. >> I think I know the reason. The GSL developers are now using sin and >> cos function from the runtime library. Before that change the >> numerical error of gsl_sf_sin and gsl_sf_cos function from GLS was >> added to the total error with >> >> result->err = fabs(f * sin_result.err/x) + fabs((3.0*cos_result.err/x)/x); >> >> in the new code sin and cos were considered as they are perfectly >> precise (sin and cos precision depends on processor and it's known >> their precision can be more, much more, greatter than 1 ulp), so the >> new implementation and the threshold used to pass the test are no >> longer OK for my (and your) processor. >> >> I'd like to change the compilation flags (using SSE2 and or >> -mfloat-store) just to see what will happen...and then using MPFR I'd >> like to understand better the reason of the failure. >> >> Hope this helps >> >> Regards >> >> Max >>