PB 6.10 beta 5 #PB_Any return value type changed?

[Justin]

This beta seems to return much bigger values when using #PB_Any when creating gadgets, using c backend x64:
PB 6.04 35915776
PB 6.10b5 2537844711072

Wich value type is returning?

[STARGÅTE]

It is and was always integer (.i)
I think there was a change in memory management in the background.

But why you think it is a bug?

[Justin]

Not really a bug but something has changed for sure.
In a program that interacts with COM what previously was interpreted as a VT_I4 (4 byte signed int) now has become a VT_R8 (8 byte floating point) it caused the program to crash.
The returned gadget handles values seem to have widened, i would like to know what has changed internally with more detail.

[mk-soft]

Not Double ...

Code: Select all

Define v1.VARIANT
v1\vt = #VT_I8
v1\llVal = adr
v1\vt = #VT_UI8
v1\ullVal = adr

[STARGÅTE]

Not really a bug but something has changed for sure.
In a program that interacts with COM what previously was interpreted as a VT_I4 (4 byte signed int) now has become a VT_R8 (8 byte floating point) it caused the program to crash.
The returned gadget handles values seem to have widened, i would like to know what has changed internally with more detail.

Here you can find my (and other's) old posts regarding this change: https://www.purebasic.fr/english/viewto ... 28#p572528

Probably in older PB versions also the 64 bit version uses something like a virtual memory address per process.
In PB 6.00 is now uses the "real" memory position which is most often above a size of a long due to the huge RAM of 8 GB to 64 GB of typical PC systems.
But this is just speculation, I'm not familiar with this topic. Perhaps Fred can answer this question.

Please read also this blog post from freak:
Is your 64bit program really solid ?

[Justin]

mk-soft, i don't understand your point

stargate, thanks but those posts are from 2 years ago, the changes in gadget handles returned from #PB_Any, happen from 6.04 to 6.10b5 not sure in b4

[Fred]

We changed the linker, it probably added randomized address allocation by default to avoid memory attack prediction. That's a good thing anyway, it will help to track 64-bit code bug like you encountered.

[juergenkulow]

Is this line of code still correct? Protected.l FileNumber

[Fred]

Is this line of code still correct? Protected.l FileNumber

It's indeed not correct, a #PB_Any result needs an integer (.i) type. I changed it.

[Justin]

So before 6.10 #PB_Any returned a long (4 bytes in x86/x64) and now returns an integer (4 bytes x86 / 8 bytes in x64)?
Thanks for the clarification.

[Fred]

No, it never returned a long. It returned an integer which by luck was fitting into a long on x64. #PB_Any returns a real memory pointer, that's why it's always been integer (and not long). To have more info about the new linker memory default setting:

https://learn.microsoft.com/en-us/cpp/b ... w=msvc-170

[Justin]

Ok, thanks

[blueb]

No, it never returned a long. It returned an integer which by luck was fitting into a long on x64. #PB_Any returns a real memory pointer, that's why it's always been integer (and not long). To have more info about the new linker memory default setting:

https://learn.microsoft.com/en-us/cpp/b ... w=msvc-170

Wow Fred (and Freak).
That's deep. You do all the hard work, so I don't have to... it's appreciated

[Justin]

Just noticed that in Windows 7 x64 with this beta the behaviour is to return small numbers like in previous PB versions, they actually fit in a long type.

This different memory behaviour between os with the same PB version can cause problems in some situations.

[STARGÅTE]

This different memory behaviour between os with the same PB version can cause problems in some situations.

Why? What kind of situation?
It doesn't matter whether a memory location is large or small, as long as you use the correct variable type: Integer.

I know, old codes here in the forum uses sometimes Long, because they where used in older PB version before the type integer was introduced. These codes should be avoided or adapted.