Weird math issue when embedding to SWI-Prolog

[tatut]

I have a weird issue with JS_Eval function in quickjs-amalgam.
If I make a standalone C program, that just does:

const char *s = "4.2 * 10";
JSValue v = JS_Eval(ctx, s, strlen(s), "EVAL", JS_EVAL_TYPE_GLOBAL);

I get back a JSValue with v.tag JS_TAG_FLOAT64 and value 42.0 as expected.
But when I compile a wrapper as shared library that is loaded into SWI-Prolog and call from there. I get back a JS_TAG_INT with value 40.
Division yields a float properly (the int!, float64! and string! are printed by a switch case). Even when stringifying a result in JS, the number is wrongly 40.

?- quickjs:js("4.2 * 10", Out).
int!
Out = 40.

?- quickjs:js(" 42 / 10", Out).
float64!
Out = 4.2.

?- quickjs:js("'value is ' + (4.2 * 10)", Out).
string!
Out = "value is 40".

I have no idea what to check, any pointers to what could be causing this when loaded as shared library, is some other code causing problems?

[bnoordhuis]

Is this with a 32 or 64 bits build? What do the shared library and the host program think sizeof(JSValue) is? If they're the same, do both sides use the same struct layout?

[tatut]

But I wouldn't expect the JS_TAG_INT being 0 to affect the string return... the code 'value is ' + (4.2 * 10) evaluates to string, but a wrong one... it looks like multiplication is somehow turning 4.2 to 4.

I have a custom C code that uses both SWI-Prolog FFI interface and QuickJS and ties it together.

[tatut]

I added bytecode dumping inside JS_EvalFunctionInternal and I'm getting the following:

?- quickjs:js("4.2 * 10", Out).
GOT SOURCE: 4.2 * 10
JS_TAG_FUNCTION_BYTECODE
EVAL:1:1: function: <eval>
  mode: sloppy
  locals:
    0: var <ret>
  stack_size: 2
  byte_code_len: 6
  opcodes: 5
        push_4          4
        push_i8         10
        mul            
        set_loc0        0    ; "<ret>"
        return         

[bytecode <eval>]int!
Out = 40.

the standalone version has this bytecode:

sizeof(JSValue) = 16
GOT SOURCE: 4.2 * 10
JS_TAG_FUNCTION_BYTECODE
EVAL:1:1: function: <eval>
  mode: sloppy
  locals:
    0: var <ret>
  stack_size: 2
  byte_code_len: 7
  opcodes: 5
        push_const8     0    ; 4.2
        push_i8         10
        mul            
        set_loc0        0    ; "<ret>"
        return         

[bytecode <eval>]type: 8
float value: 42.000000

So the problem seems to be before executing, either in parse or bytecode compilation.

[tatut]

Ok I tracked it down to actual platform strtod function that is called via js_atof.
I guess SWI-Prolog has loaded some other implementation that is faulty.

[tatut]

Ok, this seems to be a locale issue.

 printf("strtod(\"4.2\") == %f\n", strtod("4.2", NULL));
  printf("strtod(\"4,2\") == %f\n", strtod("4,2", NULL));

prints

strtod("4.2") == 4,000000
strtod("4,2") == 4,200000

[tatut]

I made an issue about this.

[chqrlie]

This is a real pain! we must find a hack to avoid strtod locale specific behavior. This is not the first encounter and it proves difficult to pinpoint because programmers don't expect this kind of issue. The only reliable solution seems to use a custom proven alternative to strtod and possibly printf to stop depending on the C library for floating point conversions and their locale alternatives.