Recent

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

Warfley

  • Sr. Member
  • ****
  • Posts: 309
Re: Implicit converison, literals and QWORD variable warning
« Reply #15 on: August 07, 2020, 03:14:44 pm »
They are like minimal rules. But not all behaviour that you see might be required, that 's what "implementation defined" means (and IIRC that is a term from K&R). See e.g. https://en.wikipedia.org/wiki/Unspecified_behavior

IOW two different C compilers might react different, but still be standards compliant. Therefore you can't advocate as anything GCC does as "the will of the standard". It might be one choice of many in the optional parts of the standard.
In C and C++ there are also differences between implementation specific behaviour, unspecified behaviour and undefined behaviour, see: https://stackoverflow.com/questions/2397984/undefined-unspecified-and-implementation-defined-behavior

Examples overflow (and therefore the conversion of unsigned to singed numbers) is undefined, therefore a big no-no as the behaviour can change on any compiler (version), optimization level or even by the time of day, you can't know. So if you try to put $FFFFFFFF into an 32 bit signed int and expect it to be -1, you just wrote a broken program

The bitshift of negative signed integers from my example above is implementation specific, meaning it is well documented but does not conform to the standard, therefore you can use it as long as you stick to the same compiler. So if you rely on -1 >> 31 == -1, this is completely fine as long as you stick to gcc
« Last Edit: August 07, 2020, 03:19:31 pm by Warfley »

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8779
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #16 on: August 07, 2020, 03:47:00 pm »
Yes, this because on some non two-complement machines actually enforcing any rule can require (many) extra instructions, which would be counter productive.

And yes, there are various gradations. In some cases standards give you a choice between options etc.

I never did much with the C language standard, but I do know K&R pretty well.  While I convert and wrap it all the time I haven't programmed much own code in C++, aside from said wrappers.  Let alone spelled out the standard.

FPK

  • Jr. Member
  • **
  • Posts: 85
Re: Implicit converison, literals and QWORD variable warning
« Reply #17 on: August 07, 2020, 06:03:15 pm »
I do not get what's the fuzz about C here. Pascal is not C/C++. In FPC the rules are very simple: if a token is encountered which consists of digits (including A-F for hex), the compiler first tries to convert it to int64 as this is the largest ordinal type (qword is strictly speaking not an ordinal type in the pascal sense). If this conversion works (done by val), fine, continue with the constant being an int64. If this fails, qword is tried (also using val) and if everthings fails, the floats. As $ffffffffffffffff (2^64-1) is accepted by val as an int64, it is handled as an int64. That's it. Very simple. Very consistent.

Testing Byte, Shortint etc. separately makes no sense in pascal. This would be a random choice. That byte is one byte etc. in pascal is only an implementation detail strictly speaking.

Warfley

  • Sr. Member
  • ****
  • Posts: 309
Re: Implicit converison, literals and QWORD variable warning
« Reply #18 on: August 07, 2020, 06:24:20 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. That does not sound simple to me, to me that sounds like compiler magic doing something I didn't want it to do. Because if I wanted -1 to be there, I would have written -1 and didn't need to type the other 15 characters.

C is in that regard much simpler, because in C, if you supply a large number you get a large number and not a tiny negative number. Also in C you can even influence for small numbers how they shall be represented, like 0LL will be 64 bit all 0.
In pascal I more often than not Feel that I don't have much control other than using casts
« Last Edit: August 07, 2020, 06:30:30 pm by Warfley »

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8779
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #19 on: August 07, 2020, 06:27:42 pm »
All this talk about C/C++ is utterly useless.

No body force you to read, nor to reply.

Back to you. But putting C/C++ mindlessly on some pedestal is not constructive.

Quote
The benefit reading other standards is to learn how properly to handle problems in any compiler,

But you don't provide any tradeoff of the C++ parsing model. You take this very minute detail, and then point out to some standard based on a total alien parsing, constant declaration and import (between compilation units) model, and conclude that changing to that model is great because it fixes a corner case, and it is all there in the standard.

No practical information, nothing.

Quote
not to reinvent the wheel.

Please go to the C++ forums that are currently discussing modular support, and tell them not to reinvent the wheel because Pascal solved that 40 years ago, they just have to adopt Pascal's everything.

See how that is received.


Quote
it seems some Pandora's boxes are opened in the core of FPC.

And all that conclusion from just one warning.  And I assume without looking at the FPC source.

Quote
In this case consistency. But you constantly ignoring that, which is your problem and I do not really care about.

I've explained the consistency several times and you chose to ignore that.

FPK

  • Jr. Member
  • **
  • Posts: 85
Re: Implicit converison, literals and QWORD variable warning
« Reply #20 on: August 07, 2020, 06:28:34 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?

Yes. If you do not ignore the text before as you did.

Warfley

  • Sr. Member
  • ****
  • Posts: 309
Re: Implicit converison, literals and QWORD variable warning
« Reply #21 on: August 07, 2020, 06:32:48 pm »
Yes. If you do not ignore the text before as you did.
Yes if you understand how it works understanding how it works is easy... I get it.

The whole point if this is easy or not is to someone who did not read the entire documentation of the compiler, who just wants to write a program.

In C that is easy, you supply a huge number, you get a huge number and not a tiny negative number.

Just imagine going into a bar and asking for a double shot vodka, but you get a single shot of water instead, and then getting told: "Well if you read the fine print on the last page of our cart it says that orders of double shots are converted to single shots of water"
« Last Edit: August 07, 2020, 06:40:30 pm by Warfley »

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #22 on: August 07, 2020, 06:36:55 pm »
Back to you. But putting C/C++ mindlessly on some pedestal is not constructive.

What is not constructive? To read well established C/C++standards?
Well ignore it freely, that is your choice.

Ignoring  fact that FPC turning uint64 constant literals to negative number is serious fundamental problem.
That is all about this "fuzz", someone here call it, already.

Is it possible that the most of people here do not see this, even I places here several examples and background clearly show that consistency here is broken?

FPK

  • Jr. Member
  • **
  • Posts: 85
Re: Implicit converison, literals and QWORD variable warning
« Reply #23 on: August 07, 2020, 06:53:36 pm »
Is it possible that the most of people here do not see this, even I places here several examples and background clearly show that consistency here is broken?

*sigh* The problem is that changing this will probably break a lot of code because before qword was available in delphi, people *assigned* $ffffffffffffffff to int64 and expected to get -1. We might be able to change this in the compiler by a switch for newer delphi versions but stuff like

var
  i : int64;
  c : longint;
 
begin
  val('$ffffffffffffffff',i,c);
  if c=0 then
    writeln('ok');
end.


cannot be solved this way. Can someone please test with different delphi versions if it writes 'ok'? This is what it narrows down to: does val for int64 accept $ffffffffffffffff or not.

I hope the people promoting changing this here are then as active as writing posts here when it is about to fix bugs caused by this change and helping people fix their broken code.

process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #24 on: August 07, 2020, 07:02:30 pm »

*sigh* The problem is that changing this will probably break a lot of code because before qword was available in delphi, people *assigned* $ffffffffffffffff to int64 and expected to get -1. We might be able to change this in the compiler by a switch for newer delphi versions but stuff like

But why "a lot of people" would place $ffffffffffffffff to int64 instead simply -1? This is nonsense for higher languages and I cannot imagine who would do that (I'm bloody professional senior programmer, BTW). Now we have uint64 as native type, thus implicity convert such literal to -1 is something have no sense at all!

Even so, for instance integer length depend on platform, right? Putting  $ffffffff to it assummng it is 32-bit signed type and actually -1 is not platform independent code, right?
« Last Edit: August 07, 2020, 07:15:13 pm by process_1 »

nanobit

  • Jr. Member
  • **
  • Posts: 85
Re: Implicit converison, literals and QWORD variable warning
« Reply #25 on: August 07, 2020, 07:05:35 pm »
In the long run (hobbyists like me are patient enough to wait decades),
FPC might adopt the unsigned interpretation of all hexadecimal literals.
This would be a breaking change, but only literals having byte 7 (of 7..0) in range $80..$FF
change their meaning (to being positive) and programmers can prepare already:
Use typecasting which is required if literal byte 7 is in range $80..$FF:
Example: uint64( $FFFFFFFFFFFFFFFF) or  int64( $FFFFFFFFFFFFFFFF)

The current concept (int64) breaks the sign-consistency:
i128 := $FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF;  // i128 negative
i128 := $FFFFFFFFFFFFFFFF;  // i128 negative
i128 := $FFFFFFFF;  // i128 positive
i128 := $FFFF;  // i128 positive

FPK

  • Jr. Member
  • **
  • Posts: 85
Re: Implicit converison, literals and QWORD variable warning
« Reply #26 on: August 07, 2020, 07:18:21 pm »

*sigh* The problem is that changing this will probably break a lot of code because before qword was available in delphi, people *assigned* $ffffffffffffffff to int64 and expected to get -1. We might be able to change this in the compiler by a switch for newer delphi versions but stuff like

But why "lot of people" would place $ffffffffffffffff to int64 instead to simply -1?

... because -1 is $ffffffff on 32 bit platforms?


Anyways, enough discussion, the behaviour can be changed by the following patch:

Code: Pascal  [Select][+][-]
  1. diff --git a/rtl/inc/sstrings.inc b/rtl/inc/sstrings.inc
  2. index 7d47640baa..e76920d7f6 100644
  3. --- a/rtl/inc/sstrings.inc
  4. +++ b/rtl/inc/sstrings.inc
  5. @@ -1170,10 +1170,10 @@ begin
  6.        exit;
  7.      end;
  8.    maxPrevValue := ValUInt(MaxUIntValue) div ValUInt(Base);
  9. -  if (base = 10) then
  10. -    maxNewValue := MaxSIntValue + ord(negative)
  11. -  else
  12. -    maxNewValue := MaxUIntValue;
  13. +//  if (base = 10) then
  14. +    maxNewValue := MaxSIntValue + ord(negative);
  15. +//  else
  16. +//    maxNewValue := MaxUIntValue;
  17.    while Code<=Length(s) do
  18.     begin
  19.       case s[Code] of
  20. @@ -1285,10 +1285,10 @@ end;
  21.          exit;
  22.        end;
  23.      maxprevvalue := maxqword div base;
  24. -    if (base = 10) then
  25. -      maxnewvalue := maxint64 + ord(negative)
  26. -    else
  27. -      maxnewvalue := maxqword;
  28. +//    if (base = 10) then
  29. +      maxnewvalue := maxint64 + ord(negative);
  30. +//    else
  31. +//      maxnewvalue := maxqword;
  32.  
  33.      while Code<=Length(s) do
  34.       begin
  35.  

I am waiting for patches fixing the resulting problems, then we will see how it turns out and we can continue to discuss.

Remy Lebeau

  • Hero Member
  • *****
  • Posts: 819
    • Lebeau Software
Re: Implicit converison, literals and QWORD variable warning
« Reply #27 on: August 07, 2020, 08:43:36 pm »
Can someone please test with different delphi versions if it writes 'ok'? This is what it narrows down to: does val for int64 accept $ffffffffffffffff or not.

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
Remy Lebeau
Lebeau Software - Owner, Developer
Internet Direct (Indy) - Admin, Developer (Support forum)

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8779
  • FPC developer.
Re: Implicit converison, literals and QWORD variable warning
« Reply #28 on: August 07, 2020, 09:15:39 pm »
Back to you. But putting C/C++ mindlessly on some pedestal is not constructive.

What is not constructive? To read well established C/C++standards?

Applying them out of context.

Quote
Ignoring  fact that FPC turning uint64 constant literals to negative number is serious fundamental problem.
That is all about this "fuzz", someone here call it, already.

So, why is it fundamental? As said (if you actually bothered to read the replies) it is a result of the base type system.

Quote
Is it possible that the most of people here do not see this, even I places here several examples and background clearly show that consistency here is broken?

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.

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.


process_1

  • Guest
Re: Implicit converison, literals and QWORD variable warning
« Reply #29 on: August 07, 2020, 09:17:59 pm »
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

Remy,

Thank you for publishing this on Embarcadero forum and to that user Emailx45 for testing.

Too bad there is no message list after compilation and console log after running in order to compare all in details.



 

TinyPortal © 2005-2018