UNICODE define

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

UNICODE define

LacaK
Hi *,

can I rely on
http://wiki.freepascal.org/User_Changes_3.0#UNICODE_define_depends_on_default_string_type_instead_of_on_target_platform

that UNICODE is defined just when String=UnicodeString and not defined
in all other cases ?

TIA

-Laco.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: UNICODE define

Jonas Maebe-2

LacaK wrote on Wed, 29 Jun 2016:

> can I rely on  
> http://wiki.freepascal.org/User_Changes_3.0#UNICODE_define_depends_on_default_string_type_instead_of_on_target_platform
>
> that UNICODE is defined just when String=UnicodeString and not  
> defined in all other cases ?

That's literally what that text says, yes. What is missing from that  
changelog entry to make this clearer?


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Severe bug (?) dividing comp variables in 3.0.0

greim
In reply to this post by LacaK
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.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: UNICODE define

LacaK
In reply to this post by Jonas Maebe-2

>> can I rely on
>>http://wiki.freepascal.org/User_Changes_3.0#UNICODE_define_depends_on_default_string_type_instead_of_on_target_platform
>>
>> that UNICODE is defined just when String=UnicodeString and not
>>defined in all other cases ?
>
> That's literally what that text says, yes. What is missing from that
>changelog entry to make this clearer?

Nothing :-))
But before I have asked here, I have searched RTL sources and I found many times lines like this:

{$ifdef FPC_OS_UNICODE}
  {$define UNICODE}
{$endif}

And this lead me to confusion, if UNICODE is really compiler define or not as far as UNICODE is defined repeatedly unit by unit

-Laco.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: UNICODE define

Jonas Maebe-2
On 29/06/16 20:16, LacaK wrote:
> But before I have asked here, I have searched RTL sources and I found
> many times lines like this:
>
> {$ifdef FPC_OS_UNICODE}
>   {$define UNICODE}
> {$endif}
>
> And this lead me to confusion, if UNICODE is really compiler define or
> not as far as UNICODE is defined repeatedly unit by unit

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Severe bug (?) dividing comp variables in 3.0.0

wkitty42
In reply to this post by greim
On 06/29/2016 10:56 AM, greim wrote:

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

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
myuser@mymachine:~/development/projects/misc$ ./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


--
  NOTE: No off-list assistance is given without prior approval.
        *Please keep mailing list traffic on the list* unless
        private contact is specifically requested and granted.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Severe bug (?) dividing comp variables in 3.0.0

Bart-48
In reply to this post by greim
On 6/29/16, greim <[hidden email]> wrote:
> 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.
>

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Severe bug (?) dividing comp variables in 3.0.0

Graeme Geldenhuys-6
In reply to this post by greim
On 2016-06-29 15:56, greim wrote:
> Dividing 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Severe bug (?) dividing comp variables in 3.0.0

Jonas Maebe-2
In reply to this post by greim
greim wrote:
>
> 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.

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Severe bug (?) dividing comp variables in 3.0.0

Bart-48
On 6/30/16, Jonas Maebe <[hidden email]> wrote:

> I'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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Severe bug (?) dividing comp variables in 3.0.0

Jonas Maebe-2

Bart wrote on Thu, 30 Jun 2016:

> On 6/30/16, Jonas Maebe <[hidden email]> wrote:
>
>> 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,

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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal