lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] [low priority] Failing unique_filepath() test on Linux


From: Vadim Zeitlin
Subject: [lmi] [low priority] Failing unique_filepath() test on Linux
Date: Sun, 1 Mar 2015 03:03:48 +0100

 Hello,

 While testing that my miscellaneous change didn't break anything, I ran
all the tests not only under MSW, but also under Linux and although I was
prepared to see some failures, I was surprised to see them in the
path_utility_test, so I looked closer at what goes on in it. And it turns
out that test_unique_filepath_with_normal_filenames() relies on the fact
that keeping a file open for writing prevents it from being deleted -- but
this is simply not the case under the Unix systems where this just keeps
the actual inode alive, but doesn't prevent the program (or anybody else)
from unlinking it.

 So the reason for the test failure is clear, but not so much the solution
to it. Disabling the tests under non-MSW platforms is an obvious option,
but I wonder if unique_path() behaviour is actually correct under Linux,
i.e. whether we really want to unlink the currently opened file, even if we
can. Perhaps we should either really prevent it from being deleted or check
if it is still being used in some other way? Of course, there is no real
urgency to do anything at all here, I just thought that it could be nice to
fix the test suite under Linux too so that I could run it from time to time
to ensure that both the code and the tests are portable.


 Just FYI the other failing tests are:

 * actuarial_table_test, authenticity_test and input_test which all fail
   to find some files, i.e. I have to install lmi properly and try
   rerunning them.
 * fenv_lmi_test because it relies on MSW-specific x87 FPU behaviour, AFAIR
   this was supposed to be fixed by my fenv_iec_559 series of patches many
   years ago.
 * system_command_test which doesn't get the expected error codes: 256 and
   32512 respectively instead of 1 and 12345.

 All the other tests pass which is really not too bad considering that no
special effort had been ever made to make them work under Linux AFAIK.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]