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

[WooBean]

@Thaddy
Your (little modified) sample code output:


Result using Inc:255
//Thaddy THINKS: should be 255/$FF; he is OK here.
It is because size of "w" is 2
Result using W+1:0
//Thaddy THINKS: should be 255/$FF: W+1 = $FF01 overflows to zero, but he's wrong!
It is because size of expression "w+1" is 8


Who is mixing variable size with expression size?

[jamie]

It's easy to  make that mistake but in fact it is a DWORD/ Integer in this case that it is getting
converted to in the end.

 So it starts off like this
 
  $FF00; and ends up like this $0000FF00;

 this now that it thinks it is a DWORD/Integer and not a WORD

 The DWORD version of HI gets called instead hence the display of 0.

EDIT:
  I ment to say it ends up as $0000FF01;

 There is no overflow


 At the very least this should work in Delphi Mode, it does not, it works the same across the board
 I just had a chat with fpk on the net and he is aware of it and bound strong to keep it that way, even if it isn't
Delphi compatible.

[Lutz Mändle]

Delphi's Hi-function treats its input value as 16-bit integer, therefore the automatic type conversion has no effect (tested on Delphi 2010).

From the delphi help (sorry for german):
In Delphi können Sie mit Hi das höherwertige Byte eines Word- oder Integer-Ausdrucks abrufen.
Anmerkung:  Hi behandelt einen Integer-Werte als 16-Bit-Wert, auch wenn es sich um einen 32-Bit-Wert handelt.

Translation:
In Delphi with Hi you can get the higher byte of a word or integer expression.
Remarks: Hi handles integer values as 16 bit value even if they are 32 bit.

The automatic type conversion occurs also in Delphi. Testing WooBeans example in Delphi gives 2 for sizeof(W) and 4 for sizeof((W+1)).

FPC's behaviour in automatic type conversion is documented in the reference guide chapter 3.1.1.

[jamie]

Does your manual also cover this ?

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

1. Function GetHI(W:WORD):Byte; Overload;
2. Begin
3.   Result := HI(W);
4. end;
5. Function GetHI(W:DWORD):WORD; OverLoad;
6. Begin
7.  Result := HI(W);
8. end;
9.  
10. procedure TForm1.Button14Click(Sender: TObject);
11.  var
12.     W:Word;
13. begin
14.     W := $FF00;
15.     Caption := GetHi(W+1).ToString;
16. end;
17.                                  

unit1.pas(332,16) Error: Can't determine which overloaded function to call

[WooBean]

@Jamie

IMHO you should write:

Caption :=  (GetHi(W+1)).ToString;

Now type helpers for function GetHi results can be determined.

[jamie]

its nice for you to offer help but the situation isn't that, I simply used the helpers which I love btw to
make it simpler to view.

 Try the example yourself with or without the (..) for the helper.

[Lutz Mändle]

The expression W+1 gives a signed integer result (longint for 32bit target, int64 for 64bit target), but there is no GetHi function with matching input type. The GetHI functions should defined as follows:

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

1. Function GetHI(W:integer):WORD; OverLoad; //for 32bit target
2. Begin
3.  Result := HI(W);
4. end;
5.  
6. Function GetHI(W:int64):WORD; OverLoad; //for 64bit target
7. Begin
8.  Result := HI(W);
9. end;
10.  

The main point in this case is, that Hi in Delphi works fundamentally different than in FPC. In Delphi (at least until D2010) is only one Hi function, which extracts the LSB+1 byte from the input value. Therefore it doesn't matter which integer type is supplied to Hi.

In FPC there are several overloaded Hi functions which are extracting the higher half of the input value.

[WooBean]

@Jamie
 I am able to do something stupid - my previous post was only reaction for "unit1.pas(332,16) Error: Can't determine which overloaded function to call" - sorry.

As far as we stay at the topic it was "discovered" that FPC has different "Hi" function from Delphi as in FPC we have overloaded variants returning nibble, byte, word or dword values but Delphi (belowed and resting in peace) returns only byte, assuming that parameter is 2 bytes size (signed or not). What is more,  presence or absence of {$mode delphi} directive does not changes FPC behaviour. Arithmetic expressions can be evaluated with different intermediate types (32 or 64 bits) even if it is the same source code but different target of compilation. 

Time to bed.
 

[jamie]

I've been around this business since the punch card days, I am sure there maybe others here even longer,
maybe back when they used dual triodes for flip flops and back before then when they used relays which is
where the term "BUG" came from, due to the fact that a bug got stuck between a set of contacts one day there
by putting a wench into the mix..

 That is what we have here, its a BUG! and its broke...

 I am done  talking about it..

 Its time to purchase the latest Delphi, it works. (Sorry)..

[Thaddy]

Jamie, in this case you are right, It is a bug (and again for now dismissed  by Jonas). Plz add to the bug report in a concise and not offensive way. I am out of options.
Plz continue on mailing list.
Also plz understand that half or more the responses here are from average users. (not to degrade then at all!!) that - may be - are used to a certain behavior where it is wrong.

[marcov]

The main point in this case is, that Hi in Delphi works fundamentally different than in FPC. In Delphi (at least until D2010) is only one Hi function, which extracts the LSB+1 byte from the input value. Therefore it doesn't matter which integer type is supplied to Hi.

That is the main point. However those multiple overloads were already in FPC before Delphi compatibility was started (read: near 20 years), so obviously one is reluctant to change this. And there is no type conversion issue, even though Jamie tries to constantly bring it back to that. Other than hi/lo this also concerns swap.

Basically code that relies on such 16-bit features was never properly ported to 32-bit delphi to begin with.

Still it should be easier to clear up such known differences and prevent them from popping up every n weeks, so I changed the report to documentation.

[Thaddy]

Which is fundamentally wrong Marco, because it is a fundamental bug. Try every other language you know I know and throw it at me....
Documenting fundamental bugs as a language feature is not acceptable. An unsigned type should never, ever be affected by a shift.
It is a bug. Period.

[marcov]

Which is fundamentally wrong Marco, because it is a fundamental bug.

No, you declare it fundamental. I declare it as a minor deviation in ancient 16-bit migratory routines that are kept the way they are not to break FPC compatibility.

And probably if it didn't require very major development to hide functions depending on mode, it would probably already have been fixed.

So yes, I think it is a pity it can't be compatible, but you and Jamie are just drumming up pointless drama imho.

[jamie]

I just checked the price of the latest Delphi, is a little steep but I think I can swing it..

 Its wasn't my intention to insult anyone helping out, if that was the impression you got.

 I don't think everyone here fully understands the problem. for those that started with FPC it may
seem to be the norm or never pushed the compiler to the point where these issues crop up.
 
  And I am fully aware of the standard of full evaluation via the integer and its been there since TP as
far as I know plus it follows the Pascal I learned in college (years ago), however,  I find that

SOmeWOrdVar := SomeWordVar+1; works as it should but you can't do that anywhere else.

even the above code gets evaluated to integer but the compiler knows how to assign it back to an WORD type.

 I've written assemblers in the past and this is what I did too however, all resulting types always fit the starting
type , the one on the left and if it was a parameter for a macro, it used the starting variable type as the results
in the equation.

  Like I said, apologies for any miss understood direction to others here, it gets frustrating after awhile..

[Thaddy]

Which is fundamentally wrong Marco, because it is a fundamental bug.

No, you declare it fundamental. I declare it as a minor deviation in ancient 16-bit migratory routines that are kept the way they are not to break FPC compatibility.

It IS fundamental: since when is  a word value $FF01 >> to $ff zero?  It isn't... only in FPC...? I can see Jamie's frustration. it is basic (not the language).
And there is no reason to fix it, although this may break existing (wrong!) code it is correct to fix it. As I wrote: mailing list.