[UNSOLVDABLE ]Frustration setting in with FPC bugs and code in general.

[Handoko]

If you said so, then lets file a bug report.

Or maybe we should test it using several versions of Delphi, especially the latest one: Delphi 10.2 Tokyo before we decide which behavior we want to follow.

[jamie]

Yes, its a dead end fight. I have reported it before, actually I think I was the one that initiated it.

 I am willing to bet that if this bug gets fixed, it will fix many other issues with doing such coding in other
states when it comes to type switching by the compiler.
 
 Also note this;;

Var
 W,I:Word;
begin
 W:= 0;
 For I := 0 To W-1 do Caption := IntTostr(I);

Also works in Delphi! it does not generate a dead loop, it simply Substracts 1 from 0 which gives you the $FFFF and the loop does the 0..65535 as it should .. Fpc treats it as a integer and generates no loop and reports an overflow.

 I hope my point gets across about the issues here.

[balazsszekely]

I hope my point gets across about the issues here.

Yes, but the above issues are minor inconveniences in my opinion. I can understand that is annoying or even frustrating when converting a large delphi project, but it can be easily fixed.

PS: Can you post a link to your bug report about function HI?

[marcov]

Note that the warning only is shown in Delphi mode.

It is also hard to see if the problem is in the change of typing (i+1) always, or that limited definitions of hi() trigger it.

[Handoko]

PS: Can you post a link to your bug report about function HI?

I think it was here:
https://bugs.freepascal.org/view.php?id=31998

[Thaddy]

Note that the warning only is shown in Delphi mode.

It is also hard to see if the problem is in the change of typing (i+1) always, or that limited definitions of hi() trigger it.

Well, the evaluation order is wrong. That's a bug. It should be a word up and until it is evaluated to a byte or in general to half the size.
There is nothing that can explain it logically otherwise. ISB.

[howardpc]

Also note this;;

Var
 W,I:Word;
begin
 W:= 0;
 For I := 0 To W-1 do Caption := IntTostr(I);

Also works in Delphi!

To my mind using an unsigned type for a loop variable and then assigning a negative value to it is the programmer's error.
Delphi apparently forgives the programmer and then changes his code to one possible interpretation of what he meant to write, so it "works".
FPC is, to my mind, correctly unforgiving. A programmer error is simply that, an error.

[WooBean]

@Thaddy,
I added 3 lines to your code sample. It may keep us more calm.

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

1. {$mode delphi}{$O+}
2. uses sysutils;
3. var
4.   W:Word;
5. begin
6.   W := $FF00;
7.   Inc(W);
8.   writeln('Result using Inc:', HI(W)); // should be 255/$FF
9.   writeln('It is because size of "w" is ',sizeof(w));
10.   W := $FF00;
11.   writeln('Result using W+1:',HI(W+1)); // should be 255/$FF: W+1 = $FF01 overflows to zero
12.   writeln('It is because size of "w+1" is ',sizeof(w+1));
13.   readln; //stay calm, do nothing
14. end.  
15.  

IMHO Pascal language compilers always used (hidden) type conversions for evaluating arithmetic expressions.

[Thaddy]

@howardpc:
- You can not have negative word values in a type safe language
- overflows on purpose are a valid instrument to a programmer: e.g. cyclic buffers and often used in e.g. signal processing.

[Thaddy]

@WooBean
If I wasn't calm I would become grumpy..... < > (which isn't a good idea given my health)
It is a bug in the compiler.

THINK. Evaluation order! Respect Size during evaluation. It is all pretty basic.

[taazz]

just a quick verification does the problem occur even when range checking is off? Have you tried the same code in delphi with range check on without problems?

[Thaddy]

just a quick verification does the problem occur even when range checking is off? Have you tried the same code in delphi with range check on without problems?

Yes.
- Delphi (D7 and 10.1 tested) evaluates the word value, which is correct.
- FPC evaluates for some reason a byte value where it should evaluate the word first. Which is not correct.

[WooBean]

@Thaddy

THINK. Evaluation order! Respect Size during evaluation. It is all pretty basic.

1. I wish for you only healthy days!
2. I am using my brain in some way but not as intensively to describe it THINKING.
3. What has evaluation order to do with your (and my addition) code sample?
4. Are you shure is there a rule of "Respect Size during evaluation"? - FPC does not know it.
5. Everything is pretty basic, of course.

[Thaddy]

@Thaddy

THINK. Evaluation order! Respect Size during evaluation. It is all pretty basic.

1. I wish for you only healthy days!
2. I am using my brain in some way but not as intensively to describe it THINKING.
3. What has evaluation order to do with your (and my addition) code sample?
4. Are you shure is there a rule of "Respect Size during evaluation"? - FPC does not know it.
4. Everything is pretty basic, of course.

See my reply above, it crossed:
1, tnx, will be OK some time in the future.
2.  not all of it 
3. The compiler knows the size of the variable it needs to evaluate and needs to respect it. It is basic for compiler engineers. Not always obvious to normal programmers. Hence they discuss the obvious..
4. Yes.
Note that the other way around FPC issues a warning that it expands a type, e.g. in the case of an integer calculation.

[Thaddy]

Note the village idiot posted the bug report... Again...