borderline errorneous error message

[440bx]

Consider this example program where a pointer to char is incorrectly compared to a byte:

Code: Pascal  [Select][+][-]

1. program _ErrorMessage;
2.  
3. function DoIt(p : pchar) : int32;
4. begin
5.   while p^ = $90 do        { $90 is not a char }
6.   begin
7.     inc(p);
8.     inc(result);
9.   end;
10. end;
11.  
12. var
13.   p : pchar;
14.  
15. begin
16.   DoIt(p);
17. end.                            
18.  

the above program produces the following error message (among others):

Code: Text  [Select][+][-]

1. Free Pascal Compiler version 3.2.2 [2024/02/26] for x86_64
2. (3104) Compiling ErrorMessage.lpr
3. H:\Dev\Tests\00_ErrorMessage\ErrorMessage.lpr(6,10) Error: (4001) Incompatible types: got "Char" expected "QWord"
4.  

The compiler complains about the type of the variable instead of complaining about the target type.  The compiler should be asking for a "char" not a "qword".

[Thaddy]

The compiler is right, your notation is incorrect;

Code: Pascal  [Select][+][-]

1. program _ErrorMessage;
2. {$pointermath on}{$modeswitch result}
3. function DoIt(p : pchar) : int32;
4. begin
5.   result := 0; //shut up
6.   while p^ = #$90 do //  <---- here     { $90 is not a char, but #$90 is!!! }
7.   begin
8.     inc(p);
9.     inc(result);
10.   end;
11. end;
12.  
13. var
14.   p : pchar = #$90#$90'AAAAAAA';
15.  
16. begin
17.   writeln(DoIt(p));
18. end.

         
Why? you are using byte notation instead of char notation....
Alternatively you can use pbyte instead of pchar.

[440bx]

The variable should determine the type of the constant it can be compared to, not the constant force the type of the variable (that makes no sense.)  Particularly in the case of a dereferenced pointer.

[Thaddy]

I do not agree as I explained, but if you feel it is wrong you can file a bug report.
I think you just did not use the correct notation and when the correct notation is used there are no errors. I tested both pchar and pbyte for you.
See my new signature, inspired by you 

[Khrys]

The variable should determine the type of the constant it can be compared to, not the constant force the type of the variable (that makes no sense.)

I agree, the message should be  Error: Incompatible types: got "QWord" expected "Char"

The compiler is right, your notation is incorrect;

While it's true that  $90  is definitely not a char constant, the point of the original post is that the compiler gets the message backwards and expects the programmer to change the entire rest of the code solely to accomodate a single type mismatch (that is likely to be a typo anyway).

[dseligo]

Some more 'expectations':

Code: Pascal  [Select][+][-]

1. var b: Byte;
2.     c: Char;
3.     s: String;
4.  
5. begin
6.   If c = 1 then ;    // Error: Incompatible types: got "Char" expected "Int64"
7.   If 1 = c then ;    // Error: Incompatible types: got "Char" expected "Int64"
8.   if b = c then ;    // Error: Incompatible types: got "Char" expected "QWord"
9.   if c = b then ;    // Error: Incompatible types: got "Char" expected "QWord"
10.   if b = '1' then ;  // Error: Incompatible types: got "Char" expected "QWord"
11.   if '1' = b then ;  // Error: Incompatible types: got "Char" expected "QWord"
12.   if 1 = '11' then ; // Error: Incompatible types: got "Byte" expected "AnsiString"
13.   if '11' = b then ; // Error: Operator is not overloaded: "Constant String" = "Byte"
14.   if b = s then ;    // Error: Incompatible types: got "Byte" expected "AnsiString"
15.   if s = b then ;    // Error: Operator is not overloaded: "AnsiString" = "Byte"
16. end.

To me it just looks like that first individual types are determined and then they are checked if they match. It looks like strings are checked first, then numbers, then chars. Order usually doesn't matter (except in last example: 's = b') and constants are checked like other operands.
IMHO, in the end, it doesn't matter much. You got your error and if it says 'got "Char" expected "Int64"' or 'got "Int64" expected "Char"' doesn't mean much.

P.S.:

The compiler complains about the type of the variable instead of complaining about the target type.  The compiler should be asking for a "char" not a "qword".

What do you mean by 'target type'? When comparing two operands if they are equal, order of operands doesn't matter.

[440bx]

What do you mean by 'target type'? When comparing two operands if they are equal, order of operands doesn't matter.

The target type of a pchar is a char, the target type of a PDWORD is a DWORD, which is determined by the de-referencing of the pointer (that's the pointer's target.)

[Zvoni]

Is it possible, that the compiler resolves/parses from right to left?

Message
"Incompatible types: got "Char" expected "QWord""

From right to left: compiler finds the constant "$90" first... "Eh? It's a numeric constant. Let's use the biggest Type for it... QWord"
Next the compiler finds the "p^".... "OK, that's a Pointer to Char.... dereferenced.... Huh?.. Why do i get a Char? I need a QWord..."

[Thaddy]

Zvoni, he just made a syntax mistake as I already explained.
Don't bark up the wrong tree.
If he dares to file a bug, the devels will ROFL.

[Khrys]

The compiler complains about the type of the variable instead of complaining about the target type.  The compiler should be asking for a "char" not a "qword".

The  QWord  here has nothing to do with the fact that  P  is a pointer; FPC spits out warnings even on explicit pointer-to-integer conversions, it's not going to insert an implicit cast here. QWord, being the natively-sized integer type (you're presumably on  x86_64) is simply the assumed type for integral constants of unspecified width. If you try to compare  P^ = -$90  for example the compiler expects  Int64  instead (while the type of  P  remains the same).

[Thaddy]

While it's true that  $90  is definitely not a char constant

Absolute and utter Nonsense: it falls firmly in the range $00-$FF.
He should have written #$90 which is the correct syntax or use PBytes.
That's what you get when a programmer mixes up C syntax with Pascal.
I am sorry, but all other answers are cow dung.
And all of you know that! That's the frustrating part. Mark it as solved.

[440bx]

Is it possible, that the compiler resolves/parses from right to left?

expressions are not parsed right to left (at least not in any Pascal compiler I've seen.)

I can't even imagine attempting to parse an expression right to left, the number of problems that would create is genuinely scary. 

That said, function/procedure parameters are usually parsed right to left in a Pascal compiler.


@Thaddy,

yes, I ran into that error as a result of a typo (actually, it wasn't quite a typo, I was thinking about bytes so I put a byte where I should have put a character.) The error message wording was a real surprise and gave me a good chuckle (surprising the compiler didn't state it expected steamed dumplings... chuckle.)  I don't know that I'd call it a bug but, it is certainly a glaring deficiency (which some of them don't seem to bother the FPC developers... oh well.)

I've suggested this in the past to you, don't comment on things which it is painfully obvious you know absolutely _nothing_ about.  Actually, when it comes to writing a compiler you've demonstrated in more than one occasion to be absolutely clueless.

If you try to compare  P^ = -$90  for example the compiler expects  Int64  instead (while the type of  P  remains the same).

No. The compiler MUST expect a character because p is a pointer to a character.  It cannot expect anything else which is why the message is erroneous.  The compiler isn't resolving the expected type correctly.

[Thaddy]

@440bx
Glad it is solved.I made that mistake myself of course at some point.
The qword comes from that the compiler can not interpret the type so it assumes a pointer. But it warns...
If the compiler can determine the type it works like a charm.
But you know that already.

[Zvoni]

Zvoni, he just made a syntax mistake as I already explained.
Don't bark up the wrong tree.
If he dares to file a bug, the devels will ROFL.

Thaddy, i did get that.
It just reminded me of an issue i reported some years ago --> https://forum.lazarus.freepascal.org/index.php/topic,44713.msg314683.html#msg314683
But i can't find the Ticket on Bugtracker you opened

[Thaddy]

That one is related to the string type discussion recently and PascalDragon explained it. With very good arguments.
PascalDragon did explain that before, so the bug report is withdrawn, not closed.
My example you refer to shows differences that are not necessarily need to be interpreted as a bug. And I agree with that.
The example is still valuable to show the differences.