[fpc-pascal] SetLength warnings - request

[Michael Van Canneyt]

On Sat, 29 Dec 2018, Jonas Maebe wrote:

> On 2018-12-29 22:00, Derek Edson wrote:
>
>> Would it not be simpler to have the compiler initialize all dynamic 
>> array variables to nil, like for string variables, which should prevent 
>> the uninitialized warning/hint without requiring special treatment for 
>> handling the SetLength function.
>> 
>> It does require that the compiler recognizes its own initialization of 
>> dynamic array variables.
>
> 1) Dynamic arrays are initialised with nil, but that is an 
> implementation detail (required by the fact that they are reference 
> counted: if they would contain random data, that would cause crashes)
> 2) Passing a reference-counted variable as a var-parameter without 
> explicitly initialising it first triggers a hint in all cases. 
> Suppressing this hint specifically for SetLength would require treating 
> it specially.
>
> There is a hint for such parameters even though the compiler knows they 
> always contain a valid value, because valid in the sense of "won't crash 
> the program" is not the same as "this is what the programmer intended". 
> The only way for the programmer to indicate to the compiler what they 
> want is by writing code.
>
> The hints about the fact that managed parameters have not been 
> explicitly initialised by the programmer are different from the hints 
> you get for other types. This means you can selectively disable these 
> hints in case you do not wish to be notified about the fact that the 
> program contains no explicit initialisation of these variables. See the 
> -vq and -vm command line parameters.
>
> You don't need to typecast dynamic arrays to pointer to initialise them 
> with nil. Simply "arr:=nil;" works. Ideally, the compiler would remove 
> this extra initialisation if you add it before it got a different value, 
> but it does not yet do that.

This is meanwhile such a FAQ, maybe we should add it somewhere in the WIKI,
Webpage, wherever ?

It's documented, but clearly not visibly enough.

Michael.