The Rio is the current version of Delphi, AFAIK
Can anyone who have Rio confirm all this?
As I wrote before, how can the compiler know if a certain bit pattern is to be interpreted as signed or unsigned given an untyped const?Easy. Tries to use a single-byte signed type that includes the value of a constant. If not, a single-byte unsigned type. If it doesn't work, then a two-byte signed type, and so on.
I don't believe Delphi 10.4 can do that, unless on use and with type inference, which would be BAD. Somebody is plain lying here....
About C++ integer literals - https://en.cppreference.com/w/cpp/language/integer_literal
From Notes -
There are no negative integer constants.
No suffix means signed. Since we have no suffix at all, we are in compliance O:-)
Seriously, the qword(literal value) on the rhs is probably equivalent to C++'s suffixes.
No suffix means signed. Since we have no suffix at all, we are in compliance O:-)
Seriously, the qword(literal value) on the rhs is probably equivalent to C++'s suffixes.
What julkas mentioned means exactly that - suffixes for integers are ignored in C++, they are always positive numbers. For negative numbers, negative sign is used.
Ok, I read better, and it say a negative literal generates a unsigned value + an unary minus operation. But how do you generate an operation for a constant? And what type does the constant have? It might be C/C++ substitution based parsing, trying to process that unary operation at every place the literal is used. I'm not sure Pascal works that way.
Moreover, as soon as you have binary operands, type promotion rules come out to play then it is not just the literal definition, but the whole evaluation on the place it is used.
p.s. As I said before: if you want to make a standards argument, you must base it purely on the text. Testing with a compiler clouds the issue with potentially implementation defined behaviour.
What julkas mentioned means exactly that - suffixes for integer literals are ignored in C++, they are always positive numbers. For negative numbers, negative sign is used. In C/C++ suffixes for hex numbers are L, LL, UL, ULL, but as wrote already, they are ignored in C++. Execute following code and you will see exact result of it:
Just post an example what you want to accomplish. Type promotion rules applies here without an issue.
Problem in FPC, however, is arbitrary rule for unwanted integer literals implicit conversion, as already pointed.
p.s. As I said before: if you want to make a standards argument, you must base it purely on the text. Testing with a compiler clouds the issue with potentially implementation defined behaviour.
All this talk about C/C++ is utterly useless.
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_behaviorIn 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
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.
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.
All this talk about C/C++ is utterly useless.
No body force you to read, nor to reply.
The benefit reading other standards is to learn how properly to handle problems in any compiler,
not to reinvent the wheel.
it seems some Pandora's boxes are opened in the core of FPC.
In this case consistency. But you constantly ignoring that, which is your problem and I do not really care about.
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.Yes if you understand how it works understanding how it works is easy... I get it.
Back to you. But putting C/C++ mindlessly on some pedestal is not constructive.
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
*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?
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.
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?
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?
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
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
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 in introduced by Delphi and when with FPC as native type.
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.
when with FPC as native type. AFAIK, that happens few years ago
Well, define few? 21 years is not few.
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.
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}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.
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 !!!!)
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.
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
hello people,
...
Thank you very much, julkas.No problem. Code -
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):
test.lpr(19,9) Warning: range check error while evaluating constants (-1 must be between 0 and 18446744073709551615)
Literal64Dec is unsigned 18446744073709551615
Literal64Hex is signed -1
Variable64 is unsigned 18446744073709551615
Literal32Dec is unsigned 4294967295
Literal32Hex is unsigned 4294967295
Variable32 is unsigned 4294967295
Literal64Dec is unsigned 18446744073709551615
Literal64Hex is unsigned 18446744073709551615
Variable64 is unsigned 18446744073709551615
Literal32Dec is unsigned 4294967295
Literal32Hex is unsigned 4294967295
Variable32 is unsigned 4294967295
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.
I think the main complaint is the difference between FPC and Delphi in interpretation of hexadecimal (only!) and 64-bit (only!) constants as a signed. And this fact is not documented.
Remark The compiler decides on the type of an integer constant based on the value: An integer constant gets the smallest possible signed type. The first match in table (3.3) is used.
Remark The compiler decides on the type of an integer constant based on the value: An integer constant gets the smallest possible signed type. The first match in table (3.3) is used.Did you read my post?
Did you read my post?
18446744073709551615 is UInt64. Unsigned because this value does not fit into Int64. But $FFFFFFFFFFFFFFFF is already Int64. It also doesn't fit into Int64. Moreover, the hexadecimal form assumes the unsigned form (do you often see -$...?).
QuoteRemark The compiler decides on the type of an integer constant based on the value: An integer constant gets the smallest possible signed type. The first match in table (3.3) is used.
It is documented (https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1):QuoteRemark The compiler decides on the type of an integer constant based on the value: An integer constant gets the smallest possible signed type. The first match in table (3.3) is used.
Personally I think you should give up..Did you read my post?
18446744073709551615 is UInt64. Unsigned because this value does not fit into Int64. But $FFFFFFFFFFFFFFFF is already Int64. It also doesn't fit into Int64. Moreover, the hexadecimal form assumes the unsigned form (do you often see -$...?).
Just do not bother yourself trying to explain them, it is useless. I have gave up already.
Remark The compiler decides on the type of an integer constant based on the value: An integer constant gets the smallest possible signed type. The first match in table (3.3) is used.Did you read my post?
18446744073709551615 is UInt64. Unsigned because this value does not fit into Int64. But $FFFFFFFFFFFFFFFF is already Int64. It also doesn't fit into Int64. Moreover, the hexadecimal form assumes the unsigned form (do you often see -$...?).
Let the compiler developers choose this, but in my opinion it's need to document that only for hexadecimal constants and only large ones (higher (Int64)) the constant is selected as negative. This is not the case for the other bits or decimal representation.
hello people,
...
Thank you in advance.
EDIT: Added code to write integers directly, by side with IntToStr().
~
Thank you julkas, once again!
Let see how FPC works in Delphi mode:
The compiler here contradict to itelf!
Now, if emailx45 can help us with results of the same code produced with Sydney, we will have elementary facts for confirmation of suspicious that Delphi compatibility is broken here.
***********************
Try
And then for varying (small and large, negative and positive) a and b.
And testing $FFFFFFFFFFFFFFFF with VAL() of course
Try
And testing $FFFFFFFFFFFFFFFF with VAL() of course
Delphi val( '$ffffffffffffffff', intVar, code)
just behaves like overloaded functions:
1) If intVar has type int64, then intVar becomes -1,
because val() implements implicit typecast from uint64 input to int64.