Recent

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

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 #15 on: August 05, 2020, 11:28:56 pm »
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


Well, from my reading of the bug report and all its comments, I see that Delphi adopted the 64-bit unsigned integer *after* FPC already had it.

It is one thing to make things compatible with Delphi which are not yet existent in FPC.   It's a whole other thing to do so when something already exists in FPC, and will have an impact on backwards compatibility of existing code.

Some consideration should probably be given (as also noted in the bug tracker thread) to making it compatible in Delphi mode, but I also think that there could probably be a bit more clarity about exactly what version of Delphi compatibility is the target for all compatibility, as that has a bearing as well.
-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)

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: Implicit converison, literals and QWORD variable warning
« Reply #16 on: August 05, 2020, 11:50:34 pm »
If using Delphi Mode would actually make Fpc compile like Delphi I would have it on by default with anything I do..
 
 I checked 3.2.0 and I see the bugs are still there with type resolving changing, calling the wrong overload when doing math within a Prototype header of a function/procedure

 on top of that I still get the "Can't determine which procedure/function to call "

 Today I used Delphi at work for at least 3 hours and I must say I hate the IDE environment of it but the code I wrote compiled and actually worked without casting the hell out of the code all over the place to ensure it calls the correct overload and does not complain about it not knowing which overload to call.

 You see with Delphi it knows enough to make the final result type to same as it was when entering the equation, executing it and finalizing it on exit thus keeping the type the same as it was when started.

 This of course aids the compiler in searching for the correct overload to execute if there is more then one copy of that signature .

 As a Recap on this..
Code: Pascal  [Select][+][-]
  1. Var
  2.  W:WORD;
  3. begin
  4.  W:= $FF;
  5.   Result := HI(W+1);
  6. End;
  7.  
The results should be 1 but its 0;


Now I shouldn't have to be forced to WORD(W+1); the compiler should know it was a WORD when it started and it should be a WORD type when it's finished. It does not have to make changes in the background as to how to it does the math because it makes no difference if the level shift it all to a Integer before doing the math, but the results must still be a WORD type because otherwise this causes the compiler to generate bad code in cases where coders are using types left than integer and not aware of this issue..



 
The only true wisdom is knowing you know nothing

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #17 on: August 06, 2020, 09:50:50 am »
Every bloody mistake and error of Delphi or Turbo Pascal must be copied.
To make it "compatible".

Not quite. With so many versions started from Turbo Pascal and numerous of bugs, that would be not possible.
What would be? Declaration for each version? I do not think so.

But with basic compiler behavior FPC involved his own bugs based on some questionable decisions, at least in this case.
Again, what is the basic rule about type promotions? To upgrade or downgrade it? That is what is questionable here.

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

Actually, where that is wrote? Can you point relevant document?
« Last Edit: August 06, 2020, 09:52:21 am by process_1 »

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Implicit converison, literals and QWORD variable warning
« Reply #18 on: August 06, 2020, 10:32:44 am »
Again: Pascal has a preference for signed types, thus it's irrelevant that an unsigned type exists that has the same width.

Actually, where that is wrote? Can you point relevant document?

For Free Pascal it's documented here at the end in front of Boolean types (also the remark in front of table 3.3). It also stems from points such as ISO Pascal only defining a signed integer type as required type.

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Implicit converison, literals and QWORD variable warning
« Reply #19 on: August 06, 2020, 11:16:01 am »
It also stems from points such as ISO Pascal only defining a signed integer type as required type.


ISO-Pascal is from 1990. The extended version (nobody uses hat) is from 1991.
It has no objects. It is just unusable.
You better take Turbo Pascal.

Another useless ISO standard.

Winni

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #20 on: August 06, 2020, 11:49:43 am »
You better take Turbo Pascal.

Another useless ISO standard.

All PASCAL's have this, J&W too.  But there are good reasons for it (see e.g. https://stackoverflow.com/questions/12781434/why-do-delphi-and-free-pascal-usually-prefer-a-signed-integer-data-type-to-unsig/12782028#12782028 ), most notably in determining range and associated checking.  Lesser languages don't have those features (and note, in C too the base type is int and not unsigned int)

The simple solution is to never use arithmetic with the largest unsigned integer and only use it for bitfields etc.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Implicit converison, literals and QWORD variable warning
« Reply #21 on: August 06, 2020, 11:50:22 am »
ISO-Pascal is from 1990. The extended version (nobody uses hat) is from 1991.
It has no objects. It is just unusable.
The goal of the ISO standards was - and still is - to be able to write compilers on very different hardware and still maintain sourcecode compatibility.
Actually it is the same with C and for the same reasons.
BTW having no objects is really meaningless in that light. C has no objects.... Both ISO Pascal / C have proven to be VERY usable.
The only thing about the ISO modes is that they never got updated, but that does not mean much. E.g. for C the only relevant update was C99.

On subject: How would one express a signed or unsigned on an untyped const with the same bitpattern? A contradiction in terms.
« Last Edit: August 06, 2020, 11:52:27 am by Thaddy »
Specialize a type, not a var.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #22 on: August 06, 2020, 11:54:48 am »

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

This is incorrect. That value is large than the signed integer type. IOW it is a hack, and range check for the type is probably broken.

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #23 on: August 06, 2020, 12:21:24 pm »

All PASCAL's have this, J&W too.  But there are good reasons for it (see e.g. https://stackoverflow.com/questions/12781434/why-do-delphi-and-free-pascal-usually-prefer-a-signed-integer-data-type-to-unsig/12782028#12782028 ), most notably in determining range and associated checking.  Lesser languages don't have those features (and note, in C too the base type is int and not unsigned int)

The simple solution is to never use arithmetic with the largest unsigned integer and only use it for bitfields etc.

Let assume FPC documentation and decision where wrong, and let focus on Delphi and Embarcadero decisions and documentations. Or better to focus on C/C++ standards as these standards are way mature. Currently there is no larger signed type than int64, but there is unsigned int64 (unt64) which is on the top on hiearchy, thus it is clear that uint64 literals should not be implicitly converted to int64, nor int32.

On C++:

Code: [Select]
#include <iostream>

using namespace std;

int main()
{
    if (0xFFFFFFFFFFFFFFFF < 0)
      cout<<"0xFFFFFFFFFFFFFFFF is less than 0!" ; 
    else
      cout<<"0xFFFFFFFFFFFFFFFF is unsigned!" ; // Always executable

    return 0;
}


In C is the same:

Code: [Select]
#include <stdio.h>

int main()
{
   
     if (0xFFFFFFFFFFFFFFFF < 0)
      printf("0xFFFFFFFFFFFFFFFF is less than 0!") ;
    else
      printf("0xFFFFFFFFFFFFFFFF is unsigned!") ; // Always executable

    return 0;
}

Anyone here read C/C++ standards? They can be considered as "Holy Grail" and the  best reference to others as they are the most mature.

For instance, in JAVA, there is no unsigned types by design, which is basic and an arbitrary decision of the Gosling,  Sheridan, and Naughton. Among missing pointers and endless revisions, that is its main flaw in design.

But here, in Pascal (as in C/C++), we have signed and unsigned integers and we know what is hierachy order for integer types and what to do with. Or we don't? I personaly believe FPC made a mess here with this arbitrary decision.

Once again, if someone have Rio, I would be interesting to see the result of upper code with literals.
« Last Edit: August 06, 2020, 01:14:32 pm by process_1 »

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Implicit converison, literals and QWORD variable warning
« Reply #24 on: August 06, 2020, 12:41:46 pm »

This is incorrect. That value is large than the signed integer type. IOW it is a hack, and range check for the type is probably broken.

Hi!

I don't get you!?

The allways used logic is

MaxUnsingnedXX = 2 *  MaxIntXX +1;

Example: 16 Bit : MaxWord = 2 * MaxSmallInt +1 : 65535 = 2 * 32767 +1

The same for 64 bit :

MaxUnit64 = 2 * MaxInt64 + 1 : 18446744073709551615  = 2 * 9223372036854775807 + 1

Where please is the error????

Winni

Tomas Hajny

  • New Member
  • *
  • Posts: 45
Re: Implicit converison, literals and QWORD variable warning
« Reply #25 on: August 06, 2020, 12:42:37 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.

Some questions:

  • What's your basis for stating that unsigned type should be "higher" than the signed type of the same size?
  • Do you recognize that constant literals (in various formats) are just literals (not necessarily related to a specific type) which need to be translated (by the compiler and/or RTL) to the corresponding numeric equivalent and that there need to be universally defined rules for such a translation in order to make such translation possible?
  • Do you realize that such universal rules are needed to ensure consistent behaviour?

With regard to number 2 above, the simplest case is as follows:
Code: [Select]
const
 HexConst = $FFFFFFFFFFFFFFFE;
begin
 WriteLn (HexConst);
end.

With regard to number 3 above, let's take the following example:
Code: [Select]
const
 HexConst = $FFFFFFFFFFFFFFFE;
var
 I: int64;
 Q: qword;
begin
 I := HexConst;
 Q := HexConst;
 I := I div 2;
 Q := Q div 2;
 WriteLn (I);
 WriteLn (Q);
end.

Obviously, the real case would be much more complicated and the programmer might not necessarily see the types involved during the calculation. The warning is there to point out that although the calculation sequence is exactly the same, there is the same constant on the input (having the same value everywhere) and the final result perfectly fits both the types involved, the final value is different (which may not be expected otherwise).

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #26 on: August 06, 2020, 12:59:04 pm »
Let assume FPC documentation and decision where wrong,

Circular reasoning. It is wrong because we assume it is wrong?

and let focus on Delphi and Embarcadero decisions and documentations.

Good, let's.  So let's revisit the history, and what happened with the 32-bit equivalents. It is a mess that only got fixed in D4 when Delphi introduced int64.

So the question then is if Delphi now has a native int128 type that can push the boundery oncemore. Also, are you testing in 32-bit or 64-bit ? Are you testing with native Delphi (win32/win64?)  or LLVM.  64-bit might have an int128 (twice the wordsize), while 32-bit might not (that would be a harder to emulate twice the wordsize).

It might be that the LLVM mobile compilers have support for higher integer emulation, and native Delphi not.

Or better to focus on C/C++ standards as these standards are way mature. Currently there is no larger signed type than int64, but there is unsigned int64 (unt64) which is on the top on hiearchy, thus it is clear that uint64 literals should not be implicitly converted to int64, nor int32.

Bingo, success!   C has postfix designations for literals to assign them the right type. Pascal does the same by a typecast that is also allowed in e.g. constant declarations.

So basically then it is equivalent.

Anything else would be non orthogonal.

Quote
Anyone here read C/C++ standards? They can be considered as "Holy Grail" and the  best reference to others as they are the most mature.

Please make your case then with citations from standards rather than examples that might be implementation defined.


Quote
For instance, in JAVA, there is no signed types by design, which is basic and an arbitrary decision of the Gosling,  Sheridan, and Naughton. Among missing pointers and endless revisions, that is its main flaw in design.

So there is no way to have a negative number? How odd.


Quote
But here, in Pascal (as in C/C++), we have signed and unsigned integers and we know what is hierachy order for integer types and what to do with. Or we don't? I personaly believe FPC made a mess here with this arbitrary decision.

And the hierarchy is clear in Pascal. The largest signed type is the top of the of all, and literals have the type, the corresponding unsigned type doesn't fit in its range so is orphaned.

Solution: have emulation for a even larger signed type. Patches welcome.

« Last Edit: August 06, 2020, 01:06:40 pm by marcov »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #27 on: August 06, 2020, 01:04:53 pm »
The allways used logic is

wrong.

Quote
MaxUnsingnedXX = 2 *  MaxIntXX +1;

Expressions of literals and integers have integers as range. The highest integer type is INTXX, the operation happens in INTXX (even emulated int64 on e.g. 32-bit x86) or register size, whatever is larger.  Hence the result is already fubared when assigning.

You are conflating abstract integer math like Windows "Calculator" with typed programming languages.   

Quote
Example: 16 Bit : MaxWord = 2 * MaxSmallInt +1 : 65535 = 2 * 32767 +1

Evaluated in the 32-bit base type (register size): works. This will probably go wrong on Turbo Pascal, but can be worked around by typecast one of the components to word (doesn't fit in 16-bit integer) , causing everything to be evaluated using emulated longint


These issues are not new, they are known from the 16-bit->32-bit transition too with all sizes divided by 2, which is why we have all the answers more or less prepared. Delphi has had 2 32-bit unsigned over the years (D4+32-bit dword and D2-D3 31-bit cardinal)

 
« Last Edit: August 06, 2020, 01:11:48 pm by marcov »

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Implicit converison, literals and QWORD variable warning
« Reply #28 on: August 06, 2020, 01:09:11 pm »
Hi!

I did not talk about typecasting nd what fits in registers,
I did talk about simple multiplying with my brain! Gosh!

And do you know this:

MaxCardinal := 2 * MaxInt32 + 1  // brain, not registers
This is  from N. Wirth  himself. In Modula II.

Winni
« Last Edit: August 06, 2020, 01:11:36 pm by winni »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #29 on: August 06, 2020, 01:14:50 pm »
I did not talk about typecasting nd what fits in registers,
I did talk about simple multiplying with my brain! Gosh!

Pascal is very fine, but not a mind reader that can guess intent. That's why there is a type system to guide such choices.

Quote
And do you know this:

MaxCardinal := 2 * MaxInt32 + 1  // brain, not registers
This is  from N. Wirth  himself. In Modula II.

But Modula-2 has CARDINAL (unsigned) as basetype, so is different. Moreover the fragment is a bit weird since in Modula2 you must always typecast with mixed types. Did this really compile, or have somebody written down something abstract (from the brain as you say) in superficial M2 notation?

 

 

TinyPortal © 2005-2018