borderline errorneous error message

[dseligo]

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.

And what should be expected in my example (reply #5) in lines 8 and 9 (both operands are variables)?
My point is: when you evaluate equation, types of operators must be compatible and their order doesn't matter. So you can't say that because one operator is variable and one operator is constant, variable's type is expected type. Maybe wording of error could be different: Error: Incompatible types: can't compare "Char" with "QWord"

[Khrys]

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

Absolute and utter Nonsense: it falls firmly in the range $00-$FF.

The compiler is right, your notation is incorrect;

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

1. // [...]
2.   while p^ = #$90 do //  <---- here     { $90 is not a char, but #$90 is!!! }
3. // [...]

         

Stop contradicting yourself, Thaddy. You yourself said that  $90  is not a char, but  #$90  is. You added the "but" part in the code comment without removing the preceding original statement that  "$90 is not a char", so you agree with it.

[Thaddy]

Either you can't read or there is a language problem and that is not on my side.
The correct answer was given in my first reply. The rest makes no sense.

[440bx]

And what should be expected in my example (reply #5) in lines 8 and 9 (both operands are variables)?

The answer to that is simple: the lvalue determines the expected and _required_ type of the rvalue.  That's it. no ifs, no buts, no parse it from middle to the top or any other "creative" hallucination.

My point is: when you evaluate equation, types of operators must be compatible and their order doesn't matter.

That's as incorrect as claiming that 1 + 1 = 73.  order _matters_.  expressions are parsed left to right and associations are made based on operator precedence. 

The error message FPC outputs in the example I provided is strictly speaking incorrect but, at least it figured out something is wrong and said something (incorrect) to that effect.

ETA:

An improvement would be "illegal expression" (which the compiler often uses and, in this case, at least wouldn't be wrong.)

[Khrys]

Either you can't read or there is a language problem and that is not on my side.

Please elaborate. For future visitors of this thread, becaues I'm not going to argue with you further. Obviously you are always right and everyone else is always wrong - how foolish of me to dare challenge Thaddy the Great.

[jamie]

Either you can't read or there is a language problem and that is not on my side.

Please elaborate. For future visitors of this thread, becaues I'm not going to argue with you further. Obviously you are always right and everyone else is always wrong - how foolish of me to dare challenge Thaddy the Great.

Please do what I did, Block him. It will save years on your life.

The blocking feature isn't perfect, it does need to be improved on, but it's better than nothing.