Recent

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

process_1

  • Guest
Implicit converison, literals and QWORD variable warning
« on: August 05, 2020, 12:33:58 pm »
If the variable is already QWORD, no point for the warning:

Code: Pascal  [Select][+][-]
  1. var
  2.   qw: QWORD;
  3. begin
  4.  
  5.   // qw:= $FFFFFFFFFFFFFFFF;  // By compiler it is -1 and it shows range check warning, literals are treated as int64?
  6.   qw:= QWORD($FFFFFFFFFFFFFFFF); // This will pass with exact cast, no warning
  7.  
  8.   writeln(inttostr(qw));
  9.  
  10.  
                                   
« Last Edit: August 05, 2020, 12:57:05 pm by process_1 »

jamie

  • Hero Member
  • *****
  • Posts: 6077
Re: Implicit converison, literals and QWORD variable issues
« Reply #1 on: August 05, 2020, 12:58:06 pm »
Yes old problem that will never get fixed.
Untyped numeric constants are supposed  adapt to the type on the left.

That also goes for doing math within a prototype parameter with constants, the compiler converts it to integer and looks for the overload for that instead of keeping with the starting type on the left.
Basically things like byte word parameters change over to integer types.

 As much as I hate Delphi lately I can say it handles this correctly.
The only true wisdom is knowing you know nothing

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #2 on: August 05, 2020, 01:14:24 pm »
But:

Code: Pascal  [Select][+][-]
  1.  
  2.   if qw < 0 then  // Warning: Comparison might be always false due to range of constant and expression
  3.      Writeln('QWORD variable s less than 0!?!');   // Warning: unreachable code
  4.  
  5.   if word($FFFFFFFFFFFFFFFF) < 0 then
  6.      Writeln('Cast unsigned QWORD is less than 0!?!');    // Warning: unreachable code
  7.  
  8.   if $FFFFFFFFFFFFFFFF < 0 then
  9.      Writeln('Uncast literal $FFFFFFFFFFFFFFFF is treated as -1 !');  // It is always executed
  10.  
« Last Edit: August 05, 2020, 01:24:26 pm by process_1 »

jamie

  • Hero Member
  • *****
  • Posts: 6077
Re: Implicit converison, literals and QWORD variable warning
« Reply #3 on: August 05, 2020, 01:33:54 pm »
But:

Code: Pascal  [Select][+][-]
  1.  
  2.   if qw < 0 then  // Warning: Comparison might be always false due to range of constant and expression
  3.      Writeln('QWORD variable s less than 0!?!');   // Warning: unreachable code
  4.  
  5.   if word($FFFFFFFFFFFFFFFF) < 0 then
  6.      Writeln('Cast unsigned QWORD is less than 0!?!');    // Warning: unreachable code
  7.  
  8.   if $FFFFFFFFFFFFFFFF < 0 then
  9.      Writeln('Uncast literal $FFFFFFFFFFFFFFFF is treated as -1 !');  // It is always executed
  10.  

Yes of course. That is the only time it should dominate.
The only true wisdom is knowing you know nothing

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: Implicit converison, literals and QWORD variable warning
« Reply #4 on: August 05, 2020, 02:45:29 pm »
If the variable is already QWORD, no point for the warning:

Code: Pascal  [Select][+][-]
  1. var
  2.   qw: QWORD;
  3. begin
  4.  
  5.   // qw:= $FFFFFFFFFFFFFFFF;  // By compiler it is -1 and it shows range check warning, literals are treated as int64?
  6.   qw:= QWORD($FFFFFFFFFFFFFFFF); // This will pass with exact cast, no warning
  7.  
  8.   writeln(inttostr(qw));
  9.  
  10.  
                                 

Pascal languages prefer signed types to unsigned types thus such a constant is treated as Int64 instead of QWord. This is by design.

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #5 on: August 05, 2020, 03:38:41 pm »
Pascal languages prefer signed types to unsigned types thus such a constant is treated as Int64 instead of QWord. This is by design.

What is the behavior of recent Delphi release for such clauses?

But, is this the point of such ridicilous warnings that compiler have to teach me what I want  (???) , or that I tell to compiler exactly what I want?

For example, such  unsigned 64-bit constants I used as:

Code: Pascal  [Select][+][-]
  1. const
  2.   c64: array [0..1] of QWord =
  3.     (
  4.     $0000000000000000,
  5.     $FFFFFFFFFFFFFFFF
  6.     );
  7.  

Certainly, this implies that compiler is not smart at all if he force me or warining me to write something like this:

Code: Pascal  [Select][+][-]
  1. const
  2.   c64: array [0..1] of QWord =
  3.     (
  4.     QWord($0000000000000000),
  5.     QWord($FFFFFFFFFFFFFFFF)
  6.     );
  7.  

That is insane, as I aleady expicitly told to compiler what type of data I use.
« Last Edit: August 05, 2020, 08:32:19 pm by process_1 »

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: Implicit converison, literals and QWORD variable warning
« Reply #6 on: August 05, 2020, 03:59:33 pm »
But, is this the point of such ridicilous warnings that compiler have to teach me what I want  (???) , or that I tell to compiler exactly what I want?

Best read the comments of this bug report which was essentially about the same topic.

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #7 on: August 05, 2020, 08:06:40 pm »
Best read the comments of this bug report which was essentially about the same topic.

And this bug report was rejected?

The Rio is the current version of Delphi, AFAIK, then:

http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants

Here, the 64-bit native integer type is marked as such and UInt64 is also eqivalent type. This should meant that this should never be executed:

Code: Pascal  [Select][+][-]
  1.   if $FFFFFFFFFFFFFFFF < 0 then // This should'n give warning  on Rio
  2.      Writeln('Uncast literal $FFFFFFFFFFFFFFFF is treated as -1 !');  // It should never be executed on Rio
  3.  

Can anyone who have Rio confirm all this?

If the compiler support Uint64 natively, then that is the highest integer type, not int64. Decision that that is int64 have no sense at all.
« Last Edit: August 05, 2020, 09:57:27 pm by process_1 »

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Implicit converison, literals and QWORD variable warning
« Reply #8 on: August 05, 2020, 10:04:54 pm »

If the compiler support Uint64 natively, then that is the highest integer type, not int64. Decision that that is int64 have no sense at all.

Hi!

All the discussions are so liberal. We can discuss about anything.

And if someone - like you - checks that there is nonsense in the system :
It is allowed to say that.

But changes? You just said that one of The Ten Commandments is nonsense.

There will be no changes. We are here in a church . Not in a parliament!

Winni

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: Implicit converison, literals and QWORD variable warning
« Reply #9 on: August 05, 2020, 10:07:59 pm »
Best read the comments of this bug report which was essentially about the same topic.

And this bug report was rejected?

Yes.

If the compiler support Uint64 natively, then that is the highest integer type, not int64. Decision that that is int64 have no sense at all.

Again: Pascal has a preference for signed types, thus it's irrelevant that an unsigned type exists that has the same width.

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #10 on: August 05, 2020, 10:21:27 pm »
There will be no changes. We are here in a church . Not in a parliament!

Yeap, I'm well aware of inquisition existance...

But, regarding the order of types, this decision have no sense at all, period. This is the "Holy Grail" during implicit conversion. Or not?

Even with Delphi mode is declared, behavior is the same, which breaks Delphi compatibility, if that is how this works on Rio according to standard type conventions order priorities.
« Last Edit: August 06, 2020, 03:16:18 pm by process_1 »

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Implicit converison, literals and QWORD variable warning
« Reply #11 on: August 05, 2020, 10:40:23 pm »
Hi!

When N. Wirth made his first paper about Pascal he defines 4 simple types:
Integer, Real, Boolean, Char .

From the point of view "The rest is an subrange or an array of simple type" this is correct.
But the reality showed that there were two other kind of types which were badly needed:

The String and the Unsigned.

UCSD Pascal intodruced the String and the Byte
Turbo Pascal introduced the Word
Wirth himself introduced the Cardinal in Modula II. 
A lot of Pascal flavours have now a  Cardinal. Or a Word. Or both .

So Wirth recogniced his mistake.
Only fpc has  not recognized that.

Winni

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: Implicit converison, literals and QWORD variable warning
« Reply #12 on: August 05, 2020, 10:51:44 pm »
So Wirth recogniced his mistake.
Only fpc has  not recognized that.


I'm not sure I get your point on this...
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #13 on: August 05, 2020, 11:01:37 pm »
So Wirth recogniced his mistake.
Only fpc has  not recognized that.

I do not think that Wirth was involved with extensions mainly Borland/Embarcadero made. The Wirth probably hasn't had even a vision of object Pascal in his time, nor 64-bit CPUs. All what comes later is quite arbitrary, but based on some primary logic and order of things.
« Last Edit: August 05, 2020, 11:07:00 pm by process_1 »

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Implicit converison, literals and QWORD variable warning
« Reply #14 on: August 05, 2020, 11:06:54 pm »

I'm not sure I get your point on this...

Hi!

Then the other way round:

Every bloody mistake and error of Delphi or Turbo Pascal must be copied.
To make it "compatible".

But if Delphi makes something correct (seldom enough) this is not adapted:
Code: Text  [Select][+][-]
  1. $FFFFFFFFFFFFFFFF  18446744073709551615    UInt64

From http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants

Winni

 

TinyPortal © 2005-2018