David Heffernan

The entire point of a threads are to allow code to execute in parallel in the same process.

Make a minimal example that we can run. Or just debug your code.

Yes, through context switches the OS preserves the CPU and FPU state which is part of the thread context

I set the floating point control state to the Windows default (which masks exceptions) before calling any external library, and then restore it when those calls return. In order for this to work reliably in a multi-threaded environment you need to do some serious RTL patching to fix the thread safety issues. No, it is possible to fix the RTL so that you don't require such an invasive solution as you imagine. My numerical software does this. Many years ago I submitted a QC report with the attached document which explains how to fix it. Embarcadero have done nothing yet, although deleting QC meant that my report disappeared from public view! Rethinking Delphi Floating Point Control Register Management.pdf

Sure. But there are plenty of methods where you can make changes. Just because something doesn't solve all problems, doesn't mean that solving some problems isn't possible or useful. But for sure in an ideal world we would have in, out and in/out parameters implemented with the same functionality as C#. I'd be very happy to have a breaking change to the compiler and migrate my code to such a language.

Indeed. And it is simply the fact that var serves as both in/out and out that explains why there is no such warning for var parameters. Since we have out then a very simple thing for the designers to do would be to enable this very warning for var parameters too. If you encountered it on a var that was masquerading as a pure out parameter, you could simply change the parameter definition to be out.

Without the compiler enforcing it, it's next to pointless

The thing is, for value types, there is actually no practical difference between var and out in Delphi which is the problem. In practice out and var behave identically. So what's the point of out? I appreciate that legacy makes it hard to change. It was just a screw up by the designers that leads to oddities like the absent warning in this question.

A variable has to be initialized before being passed to a ref param

Because it has been designed correctly with ref, out and by value arguments handling the three different parameter semantics. C# is an example of how delphi should be, and the entire issue with this missing warning is because delphi is so badly designed in this area.

I understand all of that, hence my first post. I explained why Delphi behaves the way it does, because var is both in/out and out.

In C# you can't pass an uninitialized variable to a ref param, but you can to an out param.

I think this is because Delphi doesn't really distinguish between in/out and out semantics. Since it doesn't know whether var implies in/out or out, it can't warn, because the var parameter may be an out parameter. And yes I know that the out keyword exists but certainly for value types it is purely cosmetic. Contrast this with the clarity of C#.

Completely wrong. And rather unhelpfully so.

You weren't lucky. You were unlucky. Lucky would have been if the error had shown itself immediately. No point analysing luck. Fix your code and move on.

@Borut please don't spam the same post. Especially not by adding to the end of another old post.

sList[1] is likely the issue because sList contains 1 or fewer items. Use the debugger to confirm. Those calls to ProcessMessages look likely to cause you problems. If.not now, some time in the future.

There are likely to be other errors in such a migration. It pays to understand.

If FPC had given 9 that wouldn't have changed the conclusion

I never said anything about this specific case. I am referring to universal rules that can be applied, or in this case not because they don't exist. See the black and white cow argument.

That just tells you about this one piece of code and whichever compilers you happened to use. It doesn't prove a rule. If you look in a field and see that all the cows in that field are back and white, does that prove that all cows are black and white?

This code exhibits undefined behaviour. In an expression like a + b, a and b can be evaluated in either order. The language does not mandate that order. If you want to make your code well defined the. You need to evaluate the function on one statement, and then perform the addition in another. finalValue := ResultIsFive(index); Inc(finalValue, index);

No I don't think that is true.

AMD have their own tool I think. No idea how good it is.

This is all about the Unicode changes introduced 12 years ago in Delphi 2009. There are hundreds of posts about this. You aren't going to master this in minutes and with quick post here. You'll need to research this in depth. Start with Marco Cantù's Unicode whitepaper.