would it help if I add 'no integer;' at the beginning of the program?

I generally would not recommend making random changes - I would always rather actually understand the root cause of the problem first. You can at least do tests on your own system to see if, for example, setting environment variables allows you to replicate the behaviour that the user has reported.

I misspoke in my previous message: the environment variable I was thinking of is actually PERL5OPT. So here I see, for example:

% perl -wle 'print 3.9 * 3.9'
15.21
% export PERL5OPT='-Minteger'
% perl -wle 'print 3.9 * 3.9'
9
% export PERL5OPT='-Mbigint'
zen2% perl -wle 'print 3.9 * 3.9'
9
% export PERL5OPT=''
% perl -wle 'print 3.9 * 3.9'
15.21
%
[download]

If such tests give behaviour that matches what your user reports, then it would be reasonable a) to report the contents of that environment variable at startup, and optionally b) to clear it. But don't get me wrong - I don't think it is highly likely that a strange setting of PERL5OPT is the cause, it's just one of the few things I can think of that could affect something as fundamental as Perl's arithmetic if the perl build is otherwise functional.

I don't have a Mac, but I think it is relatively unlikely that there is so fundamental a problem on all Macs of this sort; it is more likely something specific to the environment (in the general sense) of this user's 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.

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).