Re[2]: [lmi] Unit test for C99 round()

[Vadim Zeitlin]

On Wed, 04 Jun 2008 02:20:12 +0000 Greg Chicares <address@hidden> wrote:

GC> Unless you ask me not to within twenty-four hours, I will remove
GC> 'test_ledger' from 'Makefile.am'

 No, I won't ask it.

GC> As far as I remember, no other unit-test target needs any product
GC> files other than 'sample.*', which 'product_files$(EXEEXT)' can
GC> create.

 Unfortunately I have a problem with 'product_files' too... It crashes with
SIGABRT because of the following funny sequence of events:

1. status() is called from stratified_charges::write_stratified_files()
   and, after a few more calls, throws an std::runtime_error because
   !all_function_pointers_have_been_set()

2. this exception is caught in main() which calls safely_show_message() to
   display it -- which promptly throws itself because
   safe_message_alert_function == NULL

3. as we now have an exception thrown by the exception handler,
   lmi_terminate_handler() is called which, of course, calls
   safely_show_message() -- which throws again, still without giving any
   clue to a naive user (== one not running the program under debugger)
   about what's going on

4. finally std::terminate() is called which just calls abort()

The real problem is, of course, the same one already discussed in the
"product editor patch" thread from February 2008 and the best, AFAICS,
solution was proposed by Vaclav in

   http://lists.nongnu.org/archive/html/lmi/2008-02/msg00026.html

However nothing was ever done about it, maybe we should return to this
discussion?

 However in the meanwhile I really think that safely_show_message() should
not throw, ever. Throwing is not safe as can be seen from the scenario
above.


GC> So, yes, it would be interesting to see what 'round_to_test.cpp' spews
GC> out on GNU/Linux.

 The output is small enough compressed to be attached to this email, so
I tried to do it but it bounced back with "The message's content type was
explicitly disallowed" so now I resend this message without the attachment
which I'm going to send to you directly.

 Once again, sorry but I simply didn't have time to look at the
failures details at all yet so it's perfectly possible that they're due to
something trivial.

GC> My initial hypothesis would be, though, that you're exercising
GC> a hitherto-unexplored path through the thicket of preprocessor
GC> conditionals; if so, I'm hopeful that we can fix it easily.

 All I can say is that LMI_POSIX, LMI_X86, LMI_X86_64 and __GNUC__ are all
defined in my build.

GC> [1] "that'll fail with the fifty-third Mersenne number"
...snip...

 I'm not sure if I'm going to improve my standing much at parties with this
but this is definitely a nice piece of computer floating point numbers
arithmetics to know.

 Best,
VZ