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

[jamie]

I for years used Delphi and not seen too many bugs as far as code generation, most of which were fixed..

 But since I've started to use fpc & lazarus I have come to a conclusion that because one refuses to fix a
problem they know they have and decide to brush it off as a "This is a PASCAL language constraint" basically, which
is bullocks..

  I ported various apps from Delphi that do a lot of work with Char.byte,WORD, DWORD QWORD due to their
nature in code..
 
-- This is what I have come up with that is problematic and clearly presented as real BUG that Delphi handles
correctly..

   When ever you do any and I mean any enclosed math on a type that isn't an INTEGER it converts it to a integer in
the final results and thus also causes code generation to treat it as an integer; (THIS IS IN ERROR);

 Example
   
  HI(SOMEWORD+1); results in returning a WORD of a integer, not the high byte of the WORD, in other words, the
wrong HI function was called.

  Now, do the same with creating two functions of your own OVERLOARD, and apply that same concept of math within, you'll get "CANT NOT DECIDE WHICH FUNCTION TO USE", now the compiler knows there is an issue here but
this time decides to tell you about it.. So FPC isn't totally stupid in this regard.

  Now the latest...

Var
   I, W:WORD;
Begin
  W := $FFFF; // or even 0; does not matter;

 For I := 0 to W-1 do;   // you'll get a range error if on, otherwise, this will not execute at all.

 Why? Because the action of W-1 as resulted in a integer results which means it is now  range check issue and
of coruse that loop wont execute.

 All of this can be fixed using a type cast around the math but do we need this?

 This is not restricted to using constants , it also fails using variables as the operand.

However, The compiler understands this:

SomeWordTypeVariableSomeWhere := SomeOtherWordTypeVariable-1'; or what ever.
the compiler does not complain nor does it attempt to switch it an integer;

 So why can't it so within the confines of parameters and loop control?
 
 I am sure there are other areas, this is just a beginning.

 
maybe CODE TOOLS can somehow auto insert a typecast around those types of cases when they are encountered ?

This has been a thorn in my side for some time now since I have been converted apps over using FPC, I know this
isn't a FPC complete group but I have already given up on reporting this to the bug pages.

 This is a classic example of a political brush off in my opinion

https://bugs.freepascal.org/view.php?id=33125

Sorry for the rant but I felt it worth while

[Bart]

Is current fpc behaviour in your examples different from Delphi behaviour?

Bart

[jamie]

absolutely different

I have an old copy of D3 and I have tested this on a newer version at work, D always evaluates the
final as what was started with.

 So if you use any type other than an INTEGER and do a simple offset of the value entered it always returns
the sum in the type started with (Delphi), FPC always returns Integer and thus causes compiler to treat it as such.
 
 if I do a FOR I := 0 To SomeWord-SomeValue; the loop control in Delphi still retains that it is a WORD type and
thus executes it as it should. FPC does not, this gets converted to a integer which of course then fails.

 Enjoy the battle;

Edit:
 I wanted to say, I bet this has been the cause of many bugs that randomly pop up due to values flipping over to the - side in loop controls etc.

[marcov]

Var
   I, W:WORD;
Begin
  W := $FFFF; // or even 0; does not matter;

 For I := 0 to W-1 do;   // you'll get a range error if on, otherwise, this will not execute at all.

I can't duplicate this,  (I added {$R+} and {$Q+}, and no RT errors in all major modes)

This has been a thorn in my side for some time now since I have been converted apps over using FPC, I know this
isn't a FPC complete group but I have already given up on reporting this to the bug pages.

That's still the best way to get change though.

This is a classic example of a political brush off in my opinion

https://bugs.freepascal.org/view.php?id=33125

Well, that is complicating the issue, since qword is larger than the largest integer type and a special case.

Sorry for the rant but I felt it worth while

Maybe it is wiser to start accepting that not every behaviour that Delphi exhibits is intended (or even consistent over versions).  Even less is documented.

The FPC devels have the unenviable task to guess what is meant and to condense that into rules that can be implemented in a portable way. You might give them some credit for that.

P.s. testing with D3 is not very wise, since the introduction of int64 in D4 changed a lot of this detail behaviour. D2006 and 2009 also brought considerable changes. qword is not available till XE2 ?

[Handoko]

Var
   I, W:WORD;
Begin
  W := $FFFF; // or even 0; does not matter;

 For I := 0 to W-1 do;   // you'll get a range error if on, otherwise, this will not execute at all.

I can't duplicate this,  (I added {$R+} and {$Q+}, and no RT errors in all major modes)

Me too cannot reproduce it. It just compiled and run without any error nor warning on my tests on Lazarus 1.8.0 FPC 3.0.4 Linux 64-bit.

[jamie]

You can buff this all you want, I've used Delphi for yes and TP before that..

 none of them display that behavior ..

 to simplify it, you don't need to use a int64, that was just an example and the issue still exist, with all the
common smaller types... byte, word, dword, qword etc.. none of which should ever get changed to an integer
unless otherwise forced to that state by you, the coder..
 
 Just think of loops that use non-integers types in the control path that has some initial calculated math
on the variable at the start of the loop, math that can be derived from remote sources with unknown values
and your loop needs to work with the full range of a non-integer type. What you end up with is code that randomly
fails, either with no loop taking place or a range check error if you have {$R+} .

 If one can remember to Type Cast the calculations within, then you are all set to go but I am getting old and I
never had to do this before. I don't know of any language that magically changes its type like that in places where it
can cause havoc with no warnings other than a runtime Range check if you have it on, even the Range check
code thinks it is a Integer, come on now...

 There is no amount of buffing the issue that will make it go away..

 If Code tools in Lazarus had a feature to auto TypeCast this in these cases it would fix the issue for now until it
gets fixed at the compiler level.

 This is not limited to loop control, it also causes issues in the Overloading calling of functions, changing the function that gets called, in some cases causing program bugs that are very hard to track down.

I did this with the 1.8.0 distro for windows, 3.0.4 FPC, this issue has been there for some time and is known.
compiler switches etc shouldn't have any effect on this behavior.

 

[jamie]

EDit

 As for the Loop control, if the value starts at < 0 Then it will remain the type it starts with..
 buf it the value starts with 0, it should never turn into a integer if you subtract some values from it..
 
 Compiler is treating this as a integer, the overflow is triggered and if not for that, the loop just does not
execute..
  I have code where it does such activities and is perfectly valid in Delphi.

 Also, please test the overloaded versions of functions, you'll fined the error there too.

[marcov]

You can buff this all you want, I've used Delphi for yes and TP before that..

 none of them display that behavior ..

As said I'm not aware of such behaviour, other than confusion sometimes introduced because FPC
had more overloads for things like hi/lo/swap. Newer Delphi's follow FPC in that regard though.

The point is, that without a reproducible report nothing can be done. IT is a reasonably exact science, and it should be too hard to come up with samples.

If you feel that single tickets are closed to soon, simply create a larger collection of samples to make your point that it is something fundamental.

[jamie]

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

1. procedure TForm1.Button14Click(Sender: TObject);
2.  var
3.     W:Word;
4. begin
5.     W := $FF00;
6.       Caption := HI(W+1).Tostring;
7. end;                

This is an example of what I am referring to.
you should be getting the value of 255, but it returns 0;

 Why ? because the W+1 has converted it to a Integer and not it is a DWord returning the
High WORD not the High Byte of the first..

 Simply put, any non-integer types should never convert to a integer type as the final result for a parameter to a
function nor a loop control etc..

[Handoko]

Okay, I can reproduce it now. Here is my code for testing:

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

1. procedure TForm1.Button1Click(Sender: TObject);
2. var
3.   W:Word;
4. begin
5.  
6.   W := $FF00;
7.   Inc(W);
8.   ShowMessage('Result using Inc: ' + HI(W).Tostring);
9.  
10.   W := $FF00;
11.   ShowMessage('Result using W+1: ' + HI(W+1).Tostring);
12.  
13. end;

I cannot say it is a bug or not, and I don't have Delphi for testing. I will let more experienced seniors to answer.

[marcov]

I can vaguely remember this having been brought up in Kylix times. Some fixes were done back then, which is why the basic FOR loop works.

IIRC the rationale was portability and speed of the codegenerator (more register typing would slow it down)

I would simply file the bug with the question to fix, and if for some practical reasons the compiler devs don't want to fix it, ask them to document it in a "known differences" paragraph or so.

Since back then the codegenerator has undergone massive changes for the embedded targets, so it might be doable nowadays.

Being different is one thing, but everybody having to isolate it for themselves is unnecessary.

[balazsszekely]

Just do a typecast and you're good to go:

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

1. var
2.   W: Word;
3. begin
4.   W := $FF00;
5.   Caption := HI(Word(W + 1)).ToString;
6. end;
7.  

[jamie]

That works with Delphi perfectly, like the other code I pointed out.

 For a test...

 
 Caption := HI(WORD(W+1)); will work;

 The above will work but the issue is still at large here, this is just a simple example,
this problem is causing issues all over the place when working with non initial integer types.
 
 If you were to make two functions (overloaded), one that handles lets say a byte and the other a WORD,
and call that function with math inside the parameters, the compiler will report that it can't figure out which one
to use.. , it should be obvious but is not I guess.

EDIT:
 I understand the casting fixes it but when you port code from other sources that do this correctly and its a large
app, it get a little frustrating to debug...
  Until this gets fixed, I think Code tools should have something in it to auto fix it with a type cast for now, this has
caused me issues with WHILE loops, for Loops Repeat Until etc doing binary code which works fine in Delphi and for
which most of the apps I ported came from there.
 
 Could we have code tools pick up on this maybe ?

[wp]

Why ? because the W+1 has converted it to a Integer and not it is a DWord returning the
High WORD not the High Byte of the first..

FPC at least gives you a waring "unit1.pas(43,38) Warning: lo/hi(dword/qword) returns the upper/lower word/dword". Good to look at the messages window from time to time...

[Thaddy]

Yes.
This works in Delphi. It is definitely a bug:

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 OK
9.    W := $FF00;
10.   writeln('Result using W+1:',HI(W+1)); // should be 255/$FF: W+1 = $FF01 overflows to zero NOT OK
11. end.
12.  

Although it should return a byte value it should without casting still return $FF because it needs to evaluate the word calculation W +1 first, not as byte.
Also know this bug has to my knowledge been reported already. Does not hurt to do it again.
Wrong evaluation order.....Unless it is Forth  (Nah, I know...)