Hi *,
that UNICODE is defined just when String=UnicodeString and not defined in all other cases ?
TIA
-Laco.

Mailing lists / fpc-pascal / 2016-06
11 messages · 6 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Hi *,
that UNICODE is defined just when String=UnicodeString and not defined in all other cases ?
TIA
-Laco.
LacaK wrote on Wed, 29 Jun 2016:
That's literally what that text says, yes. What is missing from that changelog entry to make this clearer?
Jonas
can I rely on http://wiki.freepascal.org/User_Changes_3.0#UNICODE_define_depends_on_defaul…
Hi,
there seems to be a very strange effect with dividing comp variables in 3.0.0:
Dividing a comp variable x by any number which is not 1 or x gives result 0.
Tested on a i386 machine.
It works fine with for example with fpc 2.6.4.
I know I can use int64 instead, but we have a lot of very old, but reliable, code around.
Example below.
Regards
Markus
--------------------------------------------------------------------------
PROGRAM compbug300;
VAR x1, x2 : comp;(* Dividing 8 / 2 doesn't work with fpc 3.0.0
but works for example with fpc 2.6.4
Markus Greim / 29.jun.2016 *)
BEGIN
x1 := 8;
writeln('x1 : ',x1);
x2 := x1 / 2;
writeln('x2 = x1/2 should be 4 but is : ', x2);
x2 := x1 / 4;
writeln('x2 = x1/4 should be 2 but is : ', x2);
x2 := x1 / 8.0;
writeln('x2 = x1/8.0 should be 1 and is : ', x2);
END.LacaK wrote on Wed, 29 Jun 2016: That's literally what that text says, yes. What is…
That's probably because instead of adapting the existing unit code to deal with the fact that the compiler now defined FPC_OS_UNICODE instead of UNICODE, someone quickly added the above code instead. It's definitely not the right way to go about things, and will completely break down completely if those units were compiled with {$modeswitch unicodestrings} since then UNICODE will be defined as well.
Jonas
there seems to be a very strange effect with dividing comp variables in 3.0.0: Dividing a…
i see the same using your code on x86_64 linux...
Free Pascal Compiler version 3.0.1 [2016/06/29] for x86_64 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Linux for x86-64
Compiling compbug300.pas
compbug300.pas(59,10) Warning: Automatic type conversion from floating type to COMP which is an integer type
Linking compbug300
/usr/bin/ld: warning: link.res contains output sections; did you forget -T? 68 lines compiled, 0.1 sec
1 warning(s) issued
2016 Jun 29 15:00:57 -0400
./compbug300
x1 : 8.000000000000000000E+0000
x2 = x1/2 should be 4 but is : 0.000000000000000000E+0000 x2 = x1/4 should be 2 but is : 0.000000000000000000E+0000 x2 = x1/8.0 should be 1 and is : 1.000000000000000000E+0000
there seems to be a very strange effect with dividing comp variables in 3.0.0: Dividing a…
Win7-64, 32-bit fpc/delphi:
C:\Users\Bart\LazarusProjecten\ConsoleProjecten\bugs\compdiv>dcc32 compbug300.lpr
Borland Delphi Version 15.0
Copyright (c) 1983,2002 Borland Software Corporation compbug300.lpr(25)
26 lines, 0.06 seconds, 12292 bytes code, 1861 bytes data.
C:\Users\Bart\LazarusProjecten\ConsoleProjecten\bugs\compdiv>compbug300 x1 : 8.0000
x2 = x1/2 should be 4 but is : 4.0000
x2 = x1/4 should be 2 but is : 2.0000
x2 = x1/8.0 should be 1 and is : 1.0000
C:\Users\Bart\LazarusProjecten\ConsoleProjecten\bugs\compdiv>fpc compbug300.lpr Free Pascal Compiler version 3.0.0 [2015/11/16] for i386 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling compbug300.lpr
compbug300.lpr(20,10) Warning: Automatic type conversion from floating type to C OMP which is an integer type
Linking compbug300.exe
24 lines compiled, 0.1 sec, 34800 bytes code, 2436 bytes data 1 warning(s) issued
C:\Users\Bart\LazarusProjecten\ConsoleProjecten\bugs\compdiv>compbug300 x1 : 8.0000
x2 = x1/2 should be 4 but is : 0.0000
x2 = x1/4 should be 2 but is : 0.0000
x2 = x1/8.0 should be 1 and is : 1.0000
C:\Users\Bart\LazarusProjecten\ConsoleProjecten\bugs\compdiv>fpc compbug300.lpr Free Pascal Compiler version 2.6.4 [2014/03/06] for i386 Copyright (c) 1993-2014 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling compbug300.lpr
compbug300.lpr(20,10) Warning: Automatic type conversion from floating type to C OMP which is an integer type
Linking compbug300.exe
24 lines compiled, 0.7 sec , 30816 bytes code, 1932 bytes data 1 warning(s) issued
C:\Users\Bart\LazarusProjecten\ConsoleProjecten\bugs\compdiv>compbug300 x1 : 8.0000
x2 = x1/2 should be 4 but is : 4.0000
x2 = x1/4 should be 2 but is : 2.0000
x2 = x1/8.0 should be 1 and is : 1.0000
Bart
there seems to be a very strange effect with dividing comp variables in 3.0.0: Dividing a…
greim wroteDividing a comp variable x by any number which is not 1 or x gives result 0.
I think you stumbled across the huge floating point bug detected just after the FPC 3.0 release - I believe that was already fixed in FPC Trunk and the 3.0.1 "fixes" branch.
If I'm wrong, then this is yet another floating point bug in FPC 3.0 release.
Regards,
Graeme
there seems to be a very strange effect with dividing comp variables in 3.0.0: Dividing a…
I've fixed it in trunk. I'll merge it later so it will also be in 3.0.2
In the future, please do not reply to existing messages when starting a new thread, it messes up automatic threading in many mail clients. Additionally, please report bugs at http://bugs.freepascal.org. On the mailing list it's easy for them to get forgotten if they are not acted upon immediately.
Jonas
Jonas Maebe wroteI've fixed it in trunk. I'll merge it later so it will also be in 3.0.2
Great.
Additionally, please report bugs at http://bugs.freepascal.org. On the mailing list it's easy for them to get forgotten if they are not acted upon immediately.
OP asked for confirmation of the bug here first, which I think is quite sensible and I wish others would do so as well, since it will stop the bugtracker from getting polluted with bugreports that are either no bugs, or were already fixed in trunk.
Bart
Bart wrote on Thu, 30 Jun 2016:
That can be useful in case you don't know whether or not your code itself is correct, but in cases like this that is not necessary.
or were already fixed in trunk.
Filing such bugs is no problem, and in fact can be useful as an indication regarding whether the fix for that bug should be merged to the fixes branch (if it hasn't already), even if the fix is was not trivial.
Jonas