David Heffernan

Well, that's true. Lots of thread safety issues with how it handles floating point control status. But that's not that same as having a math lib.

I don't have a math lib that is publishable. I've never wanted to have or do such a thing. You must be mis-remembering.

I know how floating point math works, it's been what I've done for a living for the past 30 years. Using arbitrary epsilon values is not failsafe and relies on luck.

Floats can be compared for exact equality, in plenty of circumstances. The beginner mistake is to use some epsilon value without any sound rationale for it. Usually, and works pretty good, and for the majority of cases doesn't sound great with my numerical programming head on.

This entire approach of applying some arbitrary epsilon is rubbish. I can't imagine any scenarios where they'd be useful and I've only ever seen them used inappropriately.

The best way to deal with this is never to call any of these functions in the first place, they are all useless

We'd all like that. Prospects are not good for it happening.

There's all sorts of things that Delphi should allow as constants, but that's a long known area of significant weakness in the language.

No

Exactly!

These microbenchmarks for floating point typically are of quite limited use. I remember making a bunch of changes based on such benchmarks and then finding absolutely no impact in the actual program, presumably because the bottleneck was memory.

There's nothing to understand, the original statement from @DelphiUdIT is incorrect

You call this method I think, however that's done from Delphi CoreWebView2Profile.ClearBrowsingDataAsync Method (Microsoft.Web.WebView2.Core) | Microsoft Learn

Problem with doing this is that it will scale your window size also which is usually not what you want.

I think that's about right. The issue you were facing though is 2 rather than 1. The type that matters here is the handle type. LPPPLFHANDLE is a pointer to a handle. You were managing the pointer to correctly, but your handle was wrong. You could actually declare your function like this: // an out param function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; out handle: PPLFHANDLE): LONG; stdcall; // or a var param function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; var handle: PPLFHANDLE): LONG; stdcall; Either of these would work. I show these to give a view on conceptually what that handle param is doing. I usually prefer having a literal header translation so the version in my previous message is how I would do it. And for some function you want to be able to pass nil to indicate that you don't need the function to return a handle. In this case I'm pretty sure you'd never want to do that, you always want the handle, and so the out param version would be a reasonable translation. Hope that helps!

The key here is that PPLFHANDLE is 32 bits in a 32 bit process and 64 bits in a 64 bit process. So you need a type that has the same property. For instance any pointer, or NativeInt or NativeUInt. Now, in this case it seems that the expedient thing to do is to declare PPLFHANDLE as HGLOBAL. And in the Delphi winapi units HGLOBAL will be declared as a type that switches size based on process bitness. Actually it's NativeUInt but that's actually a detail you don't really need to know. Although it's nice to know it and help confirm the understanding! So I would do this: type PPLFHANDLE = HGLOBAL; LPPPLFHANDLE = ^PPLFHANDLE; function pp_lfopen(filename: LPSTR; lfflags: LONG; lftype: LONG; password: LPSTR; handle: LPPPLFHANDLE): LONG; stdcall; Here I am using the same types as the header file. I generally think that it's preferable to keep an API translation as close to the original as possible. The header file is a bit odd in the way it defines these types: #ifndef PPLFHANDLE #ifdef _WIN64 #define PPLFHANDLE HGLOBAL #else #define PPLFHANDLE LONG #endif #endif #ifndef LPPPLFHANDLE #ifdef _WIN64 #define LPPPLFHANDLE HGLOBAL * #else #define LPPPLFHANDLE LPLONG #endif #endif It looks like an earlier version wrongly declared PPLFHANDLE as LONG and then they've kept that mistake as they catered for 64 bit. This header code should really look like this: #ifndef PPLFHANDLE #define PPLFHANDLE HGLOBAL #endif #ifndef LPPPLFHANDLE #define LPPPLFHANDLE PPLFHANDLE * #endif

That's also wrong.

No, you can have a single definition. You just need to get it right. I doubt that. Where is the header file? Or can you show enough of it so that we can see the declaration of LPPPPLFHANDLE?

There is no such incompatibility. It's just 64 to 32 bit value truncation caused by defective code.

I mean, they've shown no interest in performance whatsoever, and even less interest in floating point code. It's as much as they can manage to vaguely support all the different compilers they have and keep them functioning.

This isn't the problem. The problem is in the incorrect header file translation. The project settings that you highlight should not be changed. They are just the reason why the code has been exposed as being incorrect. That exposure should be celebrated! It's very wrong headed to try to ignore such a mistake as you propose here.

Looks like this has always been broken but you just got lucky because the 64 bit handles happened to have values that weren't changed when your code truncated them to 32 bits. With the latest delphi your luck ran out because the values are now being changed by truncation, for whatever reason. But your code was always broken and you just got away with it. Be thankful for the new delphi version highlighting this. The mistake is in your translation of the header code. There are going to be a bunch of pointer sized types that you have erroneously translated as 32 bit longint or integer.

Would be weird to want to truncate a single (a well defined task) and insist on doing so in an inefficient way.

The point I think is that FMX projects masked exceptions previously by accident rather than design. Why should making an empty FMX project bring in all those units and change the floating point control state? I understand why the change to the default was made. I kind of agree with it. But changing your code to match isn't always going to be easy. I think it would be a huge task for any code base that is heavily numerical. I certainly wouldn't change.

I was interested to see different behaviour between VCL and FMX on Windows, in pre Delphi 12. I'm not sure that this is especially intentional. It happens because FMX.Platform.Win uses FMX.WebBrowser which uses FMX.WebBrowser.Win which uses System.Win.InternetExplorer which does this in its initialization FSetExceptMask(femALLEXCEPT); I guess it does this because this the IE library implementation expects exceptions to be masked. Similarly a default FMX app will use Winapi.EdgeUtils which also masks exceptions for the same reason. I actually think it makes sense to have all platforms behaving the same way and exceptions being masked by default. That being the platform standard on all of these platforms. Myself, I'm going to keep unmasking exceptions because my codebase relies on that. I hope that the Delphi RTL will continue supporting being used with exceptions unmasked.