Re: [Help-gsl] test release for GSL 2.4

[David Komanek]

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