Recent

Author Topic: Implicit converison, literals and QWORD variable warning  (Read 2781 times)

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: Implicit converison, literals and QWORD variable warning
« Reply #30 on: August 07, 2020, 09:26:56 pm »
And it has been known that time also that C sidesteps the issue by not having real constants, but substituting defines in target context, and evaluating there.  A lucky coincidence rather than something solid from "standards", but with the consequence of slow compilation.
C doesnt, but C++ has them
Code: C  [Select][+][-]
  1. constexpr auto x = 0xFFFFFFFFFFFFFFFF;

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #31 on: August 07, 2020, 09:35:39 pm »
You haven't placed anything that isn't known for 20+ years. And has been analysed to death in that period, ever since there have been attempts to define an unsigned type that is the equivalent size of the chief signed type.

You didn't read or understand what I have wrote, I'm afraid.

What is "analyzed to death" 20+ years ago? How involving uint64 will cause problems?

Don't be theatrical, please and write when uint64 is introduced by Delphi and when with FPC as native type. AFAIK, that happens few years ago and as such is hardly "analyezed to death 20+ years ago" . I bet it was introduced in FPC without any deeper though about.

The prove for that are these ridicilous warnings and implicit conversion positive large literals to negative one. And that is not fundamental bug? Perhaps it is minor glitch, then?
« Last Edit: August 07, 2020, 09:57:00 pm by process_1 »

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8726
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #32 on: August 07, 2020, 09:51:36 pm »
You didn't read or understand what I have wrote, I'm afraid.

What is "analyzed to death" 20+ years ago? How involving uint64 will cause problems?

Same, but 32-bit case, before int64-on-32-bit introduction. As said, initially D3 was released with a 31-bit unsigned integer. (see e.g. http://www.ebob42.eu/delphi4/language.htm )

Even GCC derivate GNU Pascal did something similar for a while that makes clear the issues involved are not fanta, since these three (Delphi, FPC, GPC) are codebases independent of each other (see https://www.gnu-pascal.de/gpc/Cardinal.html)

Quote
Don't be theatrical,

I'm not. I name easy verifiable facts. For your convenience I added some links above.

Quote
please and write when uint64 in introduced by Delphi and when with FPC as native type.

I don't know about Delphi, I think XE2, since adding 64-bit triggered a major compiler revamp. FPC was earlier, 2.2 or 2.4.

Quote
AFAIK, that happens few years ago and as such is hardly "analyezed to death". I bet it was introduced in FPC without any deeper though about.

Bet based on what? I've already mentioned the cardinal->longword migration of Delphi in the early 2000s several times.

But yes, it was introduced while it was known to be flawed. The reasoning is that it would be better to directly translate structures (e.g. winapi) to it using the correct types, and increasing 64-bit activity made that come closer, and if you didn't mix types it would be ok. (e.g. a type that is a file offset).

Keep in mind that even e.g. 64-bit file offsets are signed, on both Unix and Windows.

FPK

  • Jr. Member
  • **
  • Posts: 83
Re: Implicit converison, literals and QWORD variable warning
« Reply #33 on: August 07, 2020, 10:00:28 pm »
when with FPC as native type. AFAIK, that happens few years ago

Well, define few? 21 years is not few.

FPK

  • Jr. Member
  • **
  • Posts: 83
Re: Implicit converison, literals and QWORD variable warning
« Reply #34 on: August 07, 2020, 10:09:34 pm »
Well, define few? 21 years is not few.

And for the record: Int64/QWord were added 1998/1999 (finally enabled 1st July 1999) to be able to add Alpha and iA64 support to FPC which was at least a good preparation for the x86-64 port in 2003/2004.

winni

  • Hero Member
  • *****
  • Posts: 1787
Re: Implicit converison, literals and QWORD variable warning
« Reply #35 on: August 07, 2020, 10:31:55 pm »
Hi!

While playing around with $FFFFFFFF and MaxUint I made a typo and detected a bug:

I typed 9xF instead of 8.
The result is astonishing:
2^36 = 68719476735
{16 * MaxDword}

Code: Pascal  [Select][+][-]
  1. const  nonsense  = $FFFFFFFFF;   // 9 x F
  2. var I : Int64;
  3.      pw : single;
  4.      s: string;
  5. begin
  6. I := nonsense;
  7. pw := log2(I);
  8. showMessage (FloatToStr(pw));
  9. s := intToStr(nonsense);
  10. showMessage (s);                
  11. end;
  12.  
  13.  
Bug report?

Winni

PS No error message from the compiler or at runtime.
« Last Edit: August 07, 2020, 10:37:10 pm by winni »

PascalDragon

  • Hero Member
  • *****
  • Posts: 2123
  • Compiler Developer
Re: Implicit converison, literals and QWORD variable warning
« Reply #36 on: August 07, 2020, 11:21:03 pm »
As $ffffffffffffffff (2^64-1) is accepted by val as an int64, it is handled as an int64. That's it. Very simple.
Is it really simple? I mean you just supplied it a huge positive number and magically it turned to -1.

From the compiler's point of view this is not a “huge positive number”, but first and formost a number pattern that is then simply treated as a negative number which is perfectly legal for it the parser/scanner to do.

Hi!

While playing around with $FFFFFFFF and MaxUint I made a typo and detected a bug:

I typed 9xF instead of 8.
The result is astonishing:
2^36 = 68719476735
{16 * MaxDword}

Code: Pascal  [Select][+][-]
  1. const  nonsense  = $FFFFFFFFF;   // 9 x F
  2. var I : Int64;
  3.      pw : single;
  4.      s: string;
  5. begin
  6. I := nonsense;
  7. pw := log2(I);
  8. showMessage (FloatToStr(pw));
  9. s := intToStr(nonsense);
  10. showMessage (s);                
  11. end;
  12.  
  13.  
Bug report?

Winni

PS No error message from the compiler or at runtime.

Why should there be some warning or error? This is a perfectly valid Int64 number... If you'd use LongInt instead then the compiler will complain.

winni

  • Hero Member
  • *****
  • Posts: 1787
Re: Implicit converison, literals and QWORD variable warning
« Reply #37 on: August 07, 2020, 11:59:18 pm »

Why should there be some warning or error? This is a perfectly valid Int64 number... If you'd use LongInt instead then the compiler will complain.

No no no.

$FFFFFFFFF is not a valid int64/uint64. (9 x F !!!!)

This has a value of 2^68

This is with a 64 bit integer logic not representable.

But a wrong value is shown without a hint or an error.
That is not ok.

Winni


marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8726
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #38 on: August 08, 2020, 12:14:17 am »

Why should there be some warning or error? This is a perfectly valid Int64 number... If you'd use LongInt instead then the compiler will complain.

No no no.

$FFFFFFFFF is not a valid int64/uint64. (9 x F !!!!)

$F means deceimal 15,  One hex digit is thus 4-bit. The last time I counted 9*4=36.

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: Implicit converison, literals and QWORD variable warning
« Reply #39 on: August 08, 2020, 12:37:58 am »
From the compiler's point of view this is not a “huge positive number”, but first and formost a number pattern that is then simply treated as a negative number which is perfectly legal for it the parser/scanner to do.
But I am a human, why should I care how the compiler sees things? The compiler is basically just a human machine interface, so it should be as friendly to use as possible, from the human perspective.

I mean we could also start writing floats as IEEE 754 numbers, from the compiler point of view this makes a lot of sense. But that doesn't mean that it makes sense for a human.

The job of the compiler (and the programming language in general) is to make programming as humanly friendly as possible, this is the whole reason we don't write assembly

emailx45

  • New member
  • *
  • Posts: 8
Re: Implicit converison, literals and QWORD variable warning
« Reply #40 on: August 08, 2020, 05:05:32 am »
hello people,

Im new here!

I have seen that the problem with UInt64 value = -1 is not problem only in Delphi (OP), but on fault of one type for "unsigned" for a big value like these.

I did the test in "online" calc on "https://calc.penjee.com/" (that certally is not build in Delphi or Larazus) and the resulted to FFFF.FFFF.FFFF.FFFF is -1, but only if the calculate is in 64bits signed, but if change to "unsigned" or  if you change to 128bits, então, the value will be 2^64-1 (18 qui.....) as expected.


more test mine here https://community.idera.com/developer-tools/programming-languages/f/delphi-language/73050/freepascal-compatibility---how-is-this-kind-of-code-compiled-in-delphi-10-3-rio-or-10-4-sydney

If we have a UInt128 or more, the problem would be solved... for while!

sorry if im wrong  :-[
« Last Edit: August 08, 2020, 05:25:48 am by emailx45 »

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #41 on: August 08, 2020, 06:38:41 am »
But I am a human, why should I care how the compiler sees things? The compiler is basically just a human machine interface, so it should be as friendly to use as possible, from the human perspective.

I mean we could also start writing floats as IEEE 754 numbers, from the compiler point of view this makes a lot of sense. But that doesn't mean that it makes sense for a human.

The job of the compiler (and the programming language in general) is to make programming as humanly friendly as possible, this is the whole reason we don't write assembly

Indeed, this is hilarious! And my point exactly that what we talking about is nonsense in higher languages!

How many times is necessary to write that white is not black and vice verse?
How many times is necessary to write that $FFFFFFFFFFFFFFFF is constant literal and positive number 2^64-1 or 18446744073709551615, not -1, regardless the platform?

How many times is necessary to write that this code is dubious?
Code: Pascal  [Select][+][-]
  1.   if $FFFFFFFFFFFFFFFF < 0 then
  2.     writeln('Uncast literal $FFFFFFFFFFFFFFFF is treated as -1 !'); // Always executable!
  3.  
  4.  


« Last Edit: August 08, 2020, 07:07:04 am by process_1 »

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #42 on: August 08, 2020, 06:53:42 am »
hello people,
...

Hello and welcome!

Thank you for your testing once again.

Can you please compile and run this on Delphi, copy and post here all compiler's messages after compilation and as well execution results?

Code: Pascal  [Select][+][-]
  1. var
  2.   qw: QWord;
  3. begin
  4.  
  5.   qw := $FFFFFFFFFFFFFFFF;
  6.  
  7.   Writeln('Write variable and constant literal');
  8.  
  9.   Writeln(qw);
  10.   Writeln($FFFFFFFFFFFFFFFF);
  11.  
  12.   Writeln;
  13.   Writeln('Write with IntToStr:');
  14.  
  15.   Writeln(IntToStr(qw));
  16.   Writeln(IntToStr($FFFFFFFFFFFFFFFF));
  17.  
  18.   if qw < 0 then
  19.     Writeln('Uncast unsigned QWORD is less than 0!?!');
  20.  
  21.   if qword($FFFFFFFFFFFFFFFF) < 0 then
  22.     Writeln('Cast unsigned QWORD is less than 0!?!');
  23.  
  24.   if $FFFFFFFFFFFFFFFF < 0 then
  25.     Writeln('Uncast literal $FFFFFFFFFFFFFFFF is treated as -1 !');    
  26.    
  27. end.
  28.  

Thank you in advance.

EDIT: Added code to write integers directly, by side with IntToStr().
« Last Edit: August 08, 2020, 09:12:54 am by process_1 »

julkas

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #43 on: August 08, 2020, 08:52:38 am »
Code -
Code: Pascal  [Select][+][-]
  1. program consta;
  2. {$IFDEF FPC}
  3. {$MODE Delphi}
  4. {$ENDIF}
  5. uses SysUtils;
  6. type
  7. QWord = UInt64;
  8.     var
  9.       qw: QWord;
  10.     begin
  11.      
  12.       qw := $FFFFFFFFFFFFFFFF;
  13.      
  14.       Writeln(IntToStr(qw));
  15.       Writeln(IntToStr($FFFFFFFFFFFFFFFF));
  16.      
  17.       if qw < 0 then
  18.         Writeln('Uncast unsigned QWORD is less than 0!?!');
  19.      
  20.       if qword($FFFFFFFFFFFFFFFF) < 0 then
  21.         Writeln('Cast unsigned QWORD is less than 0!?!');
  22.      
  23.       if $FFFFFFFFFFFFFFFF < 0 then
  24.         Writeln('Uncast literal $FFFFFFFFFFFFFFFF is treated as -1 !');    
  25.        
  26.     end.
  27.  
Output -
Code: Bash  [Select][+][-]
  1. $ dcc64 -B -NSSystem consta.pas
  2. Embarcadero Delphi for Win64 compiler version 33.0
  3. Copyright (c) 1983,2018 Embarcadero Technologies, Inc.
  4. consta.pas(15) Warning: W1012 Constant expression violates subrange bounds
  5. consta.pas(27)
  6. 28 lines, 0.08 seconds, 174868 bytes code, 63136 bytes data.
  7.  
  8. $ ./consta.exe
  9. -1
  10. -1
  11.  

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #44 on: August 08, 2020, 09:02:22 am »
Thank you very much, julkas.

This is with Rio, I suppose. All seems to work as expected here.

His IntToStr() probably have no overloaded function for QWord/uint64. Can you add this code please (code is fixed in my previous post):

Code: Pascal  [Select][+][-]
  1.       Writeln(qw);
  2.       Writeln($FFFFFFFFFFFFFFFF);
  3.  
« Last Edit: August 08, 2020, 09:41:58 am by process_1 »

 

TinyPortal © 2005-2018