I'm a newbye to github. Could somebody explain why does AppVeyor fails and how to debug this?

C:\projects\check\tests\check_check_sub.c(595) : error C2124: divide or mod by zero

It seems that MSVC has build-time check for this.

Need some help again. I've figured out how to open logs for ms builds. With nan I'll deal somehow on different compilers. But logs for platform=ms are unclear for me. Can I get tests log somehow with asserts text?

I've removed nan, finite and infinite asserts until get managed to check them on any compiler (ignoring nan's sign).

Jenkins: ok to test
^ Will start the last bit of the tests

I'm OK considering this change. However, I warn that working with floating point values is hard and determining good and meaningful comparisons is non-trivial. Can you share your expected use case for these macros and the application you are considering using them to unit test?

We use those tests in our commercial project so I cannot give full example. But it looks like this:
ck_assert_double_prec(&speed_integrated, &pos_delta, precision);
We use double instead of floating to rebase correctly in future.

Need some help again. I've figured out how to open logs for ms builds. With nan I'll deal somehow on different compilers. But logs for platform=ms are unclear for me. Can I get tests log somehow with asserts text?

Turns out that the Visual Studios build was never printing the output of the unit tests, even on failure. This is now resolved in master (this pull request). The Visual Studios build will now always emit the unit test output. Thanks for pointing this out.

There are a few failures in the unit tests. One of them I neglected to warn about, sorry about that. In addition to adding the name of the unit test to the master tests table, one will need to add the following call to the unit tests as well:

record_test_name(tcase_name());

The second failure is here:
/home/travis/build/libcheck/check/tests/check_check_master.c:379:F:Core Tests:test_check_failure_msgs:0: For test 60:Simple Tests:test_ck_assert_floating_eq_prec_min_prec Expected Assertion '-min_prec_minus_one <= 0' failed (prec): min_prec_minus_one == -1, got Assertion '-LDBL_MIN_10_EXP <= 0' failed (prec): LDBL_MIN_10_EXP == -4931

It appears that the test_ck_assert_floating_eq_prec_min_prec unit test failed (as expected) but it did not fail in the way it was expected to fail.

My main problem is that
ctest -V -R check_check
goes toooo long because of sleeps. Is there simple any way to run tests by their name or something?

There is a way to disable all the timeout tests:

./configure --disable-timeout-tests

With that you will find that unit tests run very quickly.

Well I've done some research. %Lg with default precision is confusing through 0.1 is not 0.1 because of digits at the end of number. So made macro CK_FLOATING_DIG that can be set by user to determine his own precision (for example DECIMAL_DIG for long double from C99). In documentation I wrote restriction on use of floating point numbers. And I cannot test bounds of precision because of different representations on x32 and x64 systems (or on different compilers/platforms, didn't dig for the reason). And because of big error coming from binary representation. But tests are useful in any case.

Macros for threshold and macros for eps would be added some later through for now I have no need of them in the project I work for. Eps would be next stage in experiment of improving precision of algorithms.

It's more complicated. For example, numbers 0.1f, 0.1 and 0.1l are not equal. So if someone would test float variable but second argument would be of double type (just number) the result would be erroneous.
That is because converting from one floating point type to another has loss of precision. For example if we convert float to double we would have the same 7 digits of precision. But double have 15 bits of precision. So they would show garbage.
http://stackoverflow.com/questions/3498192/c-convert-double-to-float-preserving-decimal-point-precision

So to prevent situations when user doesn't understand what is happening I added macros for every type.

Moreover if we would print a float number converted to long double type, than we would print different result than user expects to see.

For example, numbers 0.1f, 0.1 and 0.1l are not equal. So if someone would test float variable but second argument would be of double type (just number) the result would be erroneous.
That is because converting from one floating point type to another has loss of precision. For example if we convert float to double we would have the same 7 digits of precision. But double have 15 bits of precision. So they would show garbage.

This would apply for converting from a type with more precision (long double) to one with less precision (float). However, if one always converts to long double how would this result in an issue? Is there evidence that converting from float to long double results in 'garbage' (i.e. undefined behavior)?

Here is the example:
	printf("%g; %lg; %d\n", 0.1f, 0.1, 0.1f == 0.1);
// 0.1; 0.1; 0
// As shows printf they are equal, but...
	printf("%.15g; %.15lg; %d\n", 0.1f, 0.1, 0.1f == 0.1);
// 0.100000001490116; 0.1; 0
    volatile float x = 0.1f;
    volatile double y = 0.1;
    printf("%.15lg; %.15lg; %d\n", (double) x, y, ((double) x) == y);
// 0.100000001490116; 0.1; 0
// That was happening when converting float to double.

In fact float has much more than 7 decimal points. But 7 decimal can be set to desired values. All other are garbage. And converting to longer type you're just moving that garbage into precision decimal points. That's all the magic.

Although converting from one type to another will give you closest possible value. I didn't checked but it could bring much more undefined situations. For example when you expect something like 0.2 (0.20000000125...) you will get 0.199999999999999985.... And it could be closer to 0.2 than previous value. But that is only my assumption.

Floating point are very interesting to work with. I can tell about other magic. If you'll try to get difference of almost equal values, you will get significant error. And this value would be almost useless. The same error could be if you'll divide giant number upon very small number. Although sum of small numbers in 1000+ iterations will give the same useless result because of significant error came from summing operation. All those cases had to be worked out to get good results.

Having so many macros for different floating point comparisons looks rather cumbersome. Let me ask a few more questions to see if there is no other way.

The macros first store the two values being compared, then perform the computation with the local variables. Because of this, a type must be used. I do not see how this is a hard requirement. What would happen if, in the example of _ck_assert_floating_op_tol, the following was tried:

int _result = (X - Y) OP T * (D);
ck_assert_msg(_result, ...

Could this avoid knowing the exact type, leaving it up to whatever the caller specified them as?

And converting to longer type you're just moving that garbage into precision decimal points. That's all the magic.
Although converting from one type to another will give you closest possible value. I didn't checked but it could bring much more undefined situations.

Consider if one cast a float to a long double. If the original value only had a precision of 7.25 decimal places, one would expect that the long double value to have no more precision than that. The remaining digits would be expected to be noise. A user should not expect to get any additional precision by casting up. The case where it would be troublesome is if casting up resulted in a loss of precision.

What would happen if, in the example of _ck_assert_floating_op_tol, the following was tried:

It was the first suggestion I tried to implement. But I had to reject this idea because I cannot get type of variables (in C99) to apply appropriate modifiers to fprintf (i.e. %f, %lf, %Lf). The only way I can get type of macro argument is the sizeof. But sizeof(int) == sizeof(float). So it could be segmentation fault in some cases. In other it would be type mismatch and wrong results.

Consider if one cast a float to a long double. If the original value only had a precision of 7.25 decimal places, one would expect that the long double value to have no more precision than that. The remaining digits would be expected to be noise. A user should not expect to get any additional precision by casting up. The case where it would be troublesome is if casting up resulted in a loss of precision.

I think is a very bad idea. User could pass first argument as float and second argument as double. But promoting one to another will produce new digits in precision zone. The are not the same. If a macro if only for float numbers user would not be misunderstood. he already knows that float numbers must be passed.

I even had an idea to check the size of arguments. But if one would pass int or long it wouldn't work.

UPDATE: I thought about code size. If we generate three files from one .h.in file, it would decrease code amount. But I do not know autotools at the moment so I'll need some help in this case.

One more example:

    double d = 0.1;
    float f = 0.1;
    float fl = 0.1l; // in fact it would be 0.1f
    printf("%.15lf; %.15f; %.15f\n", d, f, fl);
// 0.100000000000000; 0.100000001490116; 0.100000001490116

So in case of typed macros, if constants passed to a macro they would be converted to a variable type. Thus it resolves the problem when user passes 0.1 comparing it to float variable. It would be just converted to 0.1f. But not promoted. So they would be equal.
Here is the explanation:
http://stackoverflow.com/questions/36840173/precision-loss-from-float-to-double-and-from-double-to-float

(Reasoning about floating point math is not easy...)

The link you mentioned, namely,

http://stackoverflow.com/questions/36840173/precision-loss-from-float-to-double-and-from-double-to-float

mentions that promoting a float->{double, long double} or double->{long double} does not change the value. If this is the case, does that not imply that the following:

In fact float has much more than 7 decimal points. But 7 decimal can be set to desired values. All other are garbage. And converting to longer type you're just moving that garbage into precision decimal points. That's all the magic.

is not entirely accurate, as the lower order bits of the significand field would be '0'. The following example may show this:

    volatile float x = 0.1f;
    volatile double y = 0.1;
    printf("%.15lg; %.15lg; %.15g;\n", (double) x, y, x);
    // Prints: 0.100000001490116; 0.1; 0.100000001490116;

That is, the float variable 'x' when cast to a double and printed, and printed directly, is the same value.

Consider if one cast a float to a long double.

I think is a very bad idea. User could pass first argument as float and second argument as double. But promoting one to another will produce new digits in precision zone. The are not the same.

True, but my understanding is that the new digits would be '0' and would not change the value of the data. Thus, if a user did decide to compare a float and a double, but the double happen to exactly represent the same data at the float, then the comparison would still be valid. If, however, they were not expected to be exact, then the tolerance-based macros would be appropriate, no?

I'm still leaning on the side of having one macro that casts to long double then compares. Using separate macros may be pedantic, but it may not be strictly necessary. Do you disagree?

UPDATE: I thought about code size. If we generate three files from one .h.in file, it would decrease code amount.

I'm not too concerned about the size of check.h. If a user does not use a macro in a given file then it should not impact their code size.

That is, the float variable 'x' when cast to a double and printed, and printed directly, is the same value.

Well, yes, they are the same for computer but it still may confuse a programmer who is trying to solve simple task and doesn't know what floating point is, because in decimal representation they are not the same. And it's true only for promotions. Example:

	volatile float x = 0.1;
	volatile double y = 0.1;
	fprintf(stderr, "%.15f %.15lf %d\n", x, y, (x == y));
//0.100000001490116 0.100000000000000 0

I'm not too concerned about the size of check.h. If a user does not use a macro in a given file then it should not impact their code size.

I mean the code size to maintain.

I'm still leaning on the side of having one macro that casts to long double then compares. Using separate macros may be pedantic, but it may not be strictly necessary. Do you disagree?

If I thought if isn't necessary I wouldn't rewrite all the code once again. The example is in the tests. I added one more test to show what I mean (test_ck_assert_ldouble_eq_with_conv).

And in any case float, double and long double separate macros are just give users a chance to choose. One could use ldouble macros for all types. Another does not need double and long double type. So he can use float macros. And float macros should be much faster than double (or ldouble) macros in i586 architecture. For example my tests for only one library already run for about a second. And it's just beginning.

I've added tests for expressions.

The example is in the tests. I added one more test to show what I mean (test_ck_assert_ldouble_eq_with_conv).

float x = 1.1;
long double y = x;
ck_assert_ldouble_eq(x, y);
record_failure_line_num(__LINE__);
ck_assert_ldouble_eq(x, 1.1);

I think that I understand now. At first glance one would have expected that to pass. But, the 1.1 being passed to the macro was originally a long double, were as the float was promoted, means that unless 1.1 can be exactly represented as a float then the comparison will fail. Tricky.

Reviewing the changes one more time, I am comfortable with these additions. Thanks for the effort in adding them, and thanks for the discussion. I'll update the branch, and after the checks complete I'll merge the changes in.

The last piece necessary for this work is adding platform dependent checks for NaN, right? Any thoughts on how best to achieve that in a maintainable way?

The last piece necessary for this work is adding platform dependent checks for NaN, right? Any thoughts on how best to achieve that in a maintainable way?

I'll add regular expressions to the master file. I think it can be useful when adding new API. So NaN would be just "-?nan" in the text. Another way, I could add a check to the macro and print always nan as text. But I am not sure about second solution because I do not know what user expects to see. If he always see -nan while debugging and tests would show +nan, it could confuse a little. But it's a much easier way.