<p>Am 07.04.2016 13:49 schrieb "Graeme Geldenhuys" <<a href="mailto:mailinglists@geldenhuys.co.uk">mailinglists@geldenhuys.co.uk</a>>:<br>
><br>
> On 2016-04-07 12:25, Martok wrote:<br>
> > If Move+FillChar would use out instead of var (as they should - they don't read<br>
> > the dest value, that's the whole point), that would be fixed once and for all.<br>
> > But I remember having this discussion before and apparently it was like this for<br>
> > some compatibility reason...<br>
><br>
> I was about to mention that. This was discussed before, and there was a<br>
> reason (which eludes me now) why FillChar() will not be changed. And<br>
> that is also when I came up with the FillMem() solution.<br>
></p>
<p>"out" and "var" behave different in rather subtle points and thus code that would currently work with FillChar would no longer work then or have subtle errors.</p>
<p>> If FPC starts nagging about uninitialised pointer parameters (as in the<br>
> usage by FillMem(...) ), then I am afraid there is *no solution* to get<br>
> rid of that compiler hint for FPC 2.6.4.</p>
<p>There is no warning/hint/whatever because a parameter is always assumed to be initialized (except it's am "out" one).</p>
<p>> I haven't looked at what FPC 3.0's Default() function does yet, but<br>
> maybe FPC could implement a FillMem() exactly like FillChar() but with<br>
> an out parameter instead. So then FillChar() is there for whatever<br>
> backward compatibility, and FillMem() could be used going forward to get<br>
> rid of that compiler hint.  Then again, I probably made this suggestion<br>
> in our previous discussions on this topic. ;-)</p>
<p>Default() essentially creates a variable of the given type and sets it to zero (there are optimizations for simple types).</p>
<p>Regards,<br>
Sven</p>