Am 2014-01-31 05:17, schrieb Prach Pongpanich:
On Fri, Jan 31, 2014 at 7:09 AM,  <markus.hoeni...@mhoenicka.de> wrote:
Prach Pongpanich writes:
[..]
 > (Cc:-ing #737126)
 >
> That reduced failures, but still remain the issue with "the_float" and
 > "the_double".
 >
 > Running "libdbi framework test"...
 > test_dbi.c:3732: unit test failure: sqlite3 -> libdbi connection ->
> Retrieving fields as -> test_dbi_result_get_as_longlong -> [-1] should
 > match [0] at [test_dbi.c] line [3732]
 > test_dbi.c:3733: unit test failure: sqlite3 -> libdbi connection ->
> Retrieving fields as -> test_dbi_result_get_as_longlong -> [-1] should
 > match [0] at [test_dbi.c] line [3733]
 > Running "libdbi framework test"...
 > Running "libdbi framework test"...
 > Running "libdbi framework test"...
> Completed "libdbi framework test": 397 passes, 2 failures, 0 exceptions.
 > make: *** [test-stamp] Error 1
 >

Ok, seems we're halfway there. It is certainly worth checking all the
compiler warnings that Laszlo mentioned. But the above mentioned
failures may be related to the way how libdbi converts floating
point numbers to long long values. Prach, could you please run the
test program below and report any compiler warnings as well as the
output on armel?


float2longlong.c
--8<----
#include <stdlib.h>
#include <stdio.h>

int main() {
  float bigfloat = 3.402823e+38;
  long long bigfloat_casted;

  bigfloat_casted = (long long)bigfloat;
  printf("%lld\n", bigfloat_casted);
  exit (0);
}

I've added a big double:

root@raspy-sid:~# gcc -Wall -g fd2ll.c -o fd2ll
root@raspy-sid:~# ./fd2ll
bigfloat2ll = -1
bigdouble2ll = -1

--
Prach

Thanks. I'll have to mull over this a little, but it basically means that the design of the test program is flawed. The hard-coded expected return values are not as platform-independent as we figured, because they may exceed the range of valid numbers on some platforms. One option is to forgo the hard-coded values and use constants from limits.h like LLONG_MAX instead, assuming that they are available on all platforms. We'd then have to create the string representations via snprintf() instead of hard-coding them. Problem is that I'm not aware of similar limits for floats. Do you know where to get this info from at compile time?

regards,
Markus

--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to