PosEX dosn't work on 64-bit

[mondoedp]

Hello,
I'm just trying new 15.5.2 version that resolved some issues.
I use Delphi 10.2 Tokyo.

Going forward on my tests, I noticed that, when I compile in 64-bit platform, the function StrUtils.PosEx doesnt'work properly.
(I don't call it directly, but it's used (for example) in System.IOUtils (TPath, TDirectory, TFile)).

By example:
PosEx(':','C:\SVN\Mydirectory',3) return 2 (that is the right value if I call PosEx(':','C:\SVN\Mydirectory',1))
while it must return 0 (as 32-bit does).
Also notes that in a normal vcl application (no-intraweb) it works in 64-bit too.

Perhaps it depends by some directive but I wasn't able to find it.

Could you have a check?
Thanks
Alberto Pilat

[rlebeau]

By example:
PosEx(':','C:\SVN\Mydirectory',3) return 2 (that is the right value if I call PosEx(':','C:\SVN\Mydirectory',1))
while it must return 0 (as 32-bit does).

That is something you need to report to Embarcadero, AToZed has no control over those RTL functions.

FWIW, I can't reproduce what you describe in Delphi 12.  PosEx(':','C:\SVN\Mydirectory',3) returns 0 in 64bit, as expected.

[jeroen.rottink]

Hi Albert,

Intraweb replaces the RTL functions Pos and PosEx for the 64-bit platform. This is done by IW_ApplyRTLPatch().

Code:

    // Std RTL functions Pos() and PosEx() are EXTREMELLY SLOW on x64
    // This replaces them using the pure pascal FastCode version
    // the new version is 5 to 10 times faster than the RTL version

 
All calls are redirected to IW.Common.Strings.IWPosEx.

That said. I tested it with IW15.4.2 on both 32-bit and 64-bit and both produce 0 as a result.
Calling IWPosEx directly also results in 0.

Attached my testcase.

[mondoedp]

By example:
PosEx(':','C:\SVN\Mydirectory',3) return 2 (that is the right value if I call PosEx(':','C:\SVN\Mydirectory',1))
while it must return 0 (as 32-bit does).

That is something you need to report to Embarcadero, AToZed has no control over those RTL functions.

FWIW, I can't reproduce what you describe in Delphi 12.  PosEx(':','C:\SVN\Mydirectory',3) returns 0 in 64bit, as expected.

Thanks Remy but, as I said, the normal behavior outside intraweb application works good.

The problem with PosEX happens in IW applications, so it's why I posted here the problem.
Now I'll try the patch as suggested by Jeroen.

Regards.

---

Hi Albert,

Intraweb replaces the RTL functions Pos and PosEx for the 64-bit platform. This is done by IW_ApplyRTLPatch().

Code:

    // Std RTL functions Pos() and PosEx() are EXTREMELLY SLOW on x64
    // This replaces them using the pure pascal FastCode version
    // the new version is 5 to 10 times faster than the RTL version

 
All calls are redirected to IW.Common.Strings.IWPosEx.

That said. I tested it with IW15.4.2 on both 32-bit and 64-bit and both produce 0 as a result.
Calling IWPosEx directly also results in 0.

Attached my testcase.

Thanks Jeroen,
but it still doesn't work.
I think the bug was introduced in 15.5.x (in 15.3.12 it worked for sure).
Do you have the possibility to test your case with 15.5.2?

Regards

[jeroen.rottink]

Thanks Jeroen,
but it still doesn't work.
I think the bug was introduced in 15.5.x (in 15.3.12 it worked for sure).
Do you have the possibility to test your case with 15.5.2?

Regards

No, I can't use IW15.5.2 currently. I have to release a project soon and don't want to change frameworks etc if not needed.
So my testcase in your environment doesn't produce two times 0?

[mondoedp]

Thanks Jeroen,
but it still doesn't work.
I think the bug was introduced in 15.5.x (in 15.3.12 it worked for sure).
Do you have the possibility to test your case with 15.5.2?

Regards

No, I can't use IW15.5.2 currently. I have to release a project soon and don't want to change frameworks etc if not needed.
So my testcase in your environment doesn't produce two times 0?

Exactly,
IWPosEx ever return 0, while PosEX continue to return 2.
(in 15.3.12 they both return 0 and I assume that it's correct till 15.4.2).

I wait for some action from Alexandre Machado...

[mondoedp]

Hi Alexandre,
are you able to have a look on the notified problem?

Thanks

[Alexandre Machado]

I'll have a look and get back to you ASAP

[Alexandre Machado]

The issue has been fixed. We will deliver an update very soon.

Cheers,

[Alexandre Machado]

Hi Alberto, this issue has been fixed in the new update 15.5.3.

This was broken due to a wrong compiler directive that needed to change because of the FPC compatibility.
As a positive consequence, we took care to include your test case and a few others in our unit test suite to prevent such issues in the future.