Get wrong results ntohs_() with PB 6.04 x86 Win10 x64

[infratec]

Hi,

one of my codes does not work anymore. So I did a short test:

Code: Select all

Define Test.u, Res.u

PokeA(@Test, $00)
PokeA(@Test + 1, $20)

Debug Hex(Test) + " - 2000 is Ok"
Debug Hex(ntohs_(Test)) + " - should be 20"

res = ntohs_(Test)
Debug Hex(res) + " - 20 is Ok"

Select ntohs_(Test)
  Case $0020
    Debug "Ok"
  Case $2000
    Debug "NOk"
  Default
    Debug "totally NOk"
EndSelect

I get:

2000 - 2000 is Ok
200020 - should be 20
20 - 20 is Ok
totally NOk

In my code I use the Select statement which fails now.

In PB 5.73 it worked.
Now I use 6.04 x86 asm in windows and it fails.
Also the C backend x86 fails.

I would call it a bug.

Can someone confirm this, or tell me my mistake?

[Little John]

Now I use 6.04 x86 asm in windows and it fails.
Also the C backend x86 fails.

I can confirm that.
(BTW: When using PB 6.04 x64, it's fine with both backends.)

[PeDe]

I am using Windows 7 x64 here.
With PB v6.04 x64 and x86, downloaded today, everything is correct with every IDE and compiler, x86/x64 ASM/C.

Peter

[infratec]

Hm ... strange.

I forgot: I use Win10 x64

[Little John]

... and I forgot to mention that I'm using Windows 11 (x64).
Maybe it's a Windows issue with the ntohs_() function?

[Fred]

It's because ntohs retuns an WORD (16-bit) where PB doesn't accept that for automatic imported function (minimum is .l). It's very unusual for Windows function to do so. You will need to mask it with & $FFFF to have it working as expected everywhere.

[infratec]

Ok, but ...

this does not explain why it works with PB 5.73.

The code was written with 5.73 and it was working.
Now, with the new compiler, it doesn't.
That's ugly and inconsistent.
And it was not mentioned in a changelog.

This results in unpredictable behaviour of compiled older programs when I have to do some bug fixes.
So if I have to change a language translation bug (for example) , it can result in a program with a big functional bug.

Or does this mean I have always compile older programs wih the PB version which was used at coding time?
This is also ugly, because old bugs (like scroll function with macOS mouse touch field) are not fixed.

[Fred]

I will check but I don't think I changed something in this field (might be a side effect though)

[mk-soft]

Hello Fred, you don't need to look any more.
According to your statement, the return value is always taken as a whole register.

The ASM code for X86 PB v5.73 and v6.04 is the same.

The function is described as

u_short ntohs([in] u_short netshort);

Applies to PB v5.73 and v6.04

For Windows 7 the function returns the correct value in the EAX register.
In Window 10 the function returns trash in the hight word of the EAX register.

According to the description of the function, the variable should always have been defined as an unsigned word (var.u).

Code: Select all

port.u = $2000
nport.u = ntohs_(port)
Debug Hex(nport)

[infratec]

I disagree.

Then please, provide me a full list of sysem functions which are affected,that I know where I have to add some & or type cast logic.

I await that a call of a procedure returns the correct value.
Else I have to start now to add &Fxxxxxx to every return value, because I don't know if there are 'garbage' in a register which is not of interrest for me.

It is like you order a six pack beer and get the six pack and additional 6 empty bottles.
If you don't agree with that, you get the answer: sorry you didn't order the six pack without additional empty bottles.
This can happen if we have to much empty bottles.
Please order your next six pack wit the additional comment: no extra empty bottles.
This is a bit strange.

All in all this results in:
We can not trust the PB return values of system functions.

Do you agree?

[mk-soft]

Then it is probably a bug in window 10 in the function "ntohs"

Because I always took half a crate of beer with me. Now there's too much beer in it.

[infratec]

Ok,

I went back to PB 4.31 and all versions returns 200020

So maybe I wrote the code in linux.
But this is also horrible: the code is not not directly working and you need half to a full hour for bug finding.
Which should not be a bug, because you did nothing wrong.

I did an additional test:

Code: Select all

Import ""
  ntohs.u(Value.u)
EndImport

port.u = $2000
Debug Hex(ntohs_(port))
Debug Hex(ntohs(port))

Result:

200020
200020

Even if I specify the return value as .u it 'returns' something larger.
This is not correct. (in my opinion)

[Fred]

It's good to know there is no regression here, but mostly an unsupported feature. Of course it's not great but as said such API in Windows is very rare so no need to panic (I don't know any other tbh). I will see if it's possible to add this type support for imported functions.