Re^4: weird problem with macports perl on apple m1/m2 based system

Ok, if I add 'use integer;' or 'use bigint;' (in both cases the behavior here is the same) to the test script and then run it on my Intel PC with Linux, I get the following output:

12.00
16.00
192
[download]

While the Mac M1 user gets:

12.99
16.25
192
[download]

Basically on the Mac M1 only in the last 'eval' (the one with the multiplication of the previous two values) the decimals get ignored, they don't get ignored everywhere and that's what makes this problem so strange, if he had some env setting that forces integer then all values would be integer like in my test that I just did with 'use integer;'.

I don't think it's a fundamental Mac M1 problem either, but I'm suspecting that maybe Perl and/or the Perl-Tk module from MacPorts for the M1 cpu have been compiled with some incorrect flags that cause this behaviour.

That's why I was hoping that maybe somebody else here can reproduce the issue on a M1 or M2 Mac with the test script.

Comment on Re^4: weird problem with macports perl on apple m1/m2 based system Select or Download Code

Replies are listed 'Best First'.
Re^5: weird problem with macports perl on apple m1/m2 based system by Anonymous Monk on Jun 11, 2023 at 06:15 UTC
If any ideas are welcome: `locale` is somehow active and `sprintf` produces strings `$x` and `$y` with comma as decimal point, then `eval('$x * $y')` would give 192 (and warnings ignored by user).	[reply] [d/l] [select]