[fpc-devel] Managed Types, Undefined Bhaviour

[Florian Klämpfl]

Am 30.06.2018 um 12:02 schrieb Willibald Krenn:
>> Gesendet: Samstag, 30. Juni 2018 um 10:54 Uhr
>> Von: "Michael Van Canneyt" <michael at freepascal.org>
>>> Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
>>>> The variables we're talking about here *are* initialized.
>>
> 
> Bit lost here. Maybe A and B are setup, but not result. And the apparent re-use of tmp vars also seems wrong. In the first call you get a "setup" var, in the second call an "initialized" one with previous values. But the latter is not commonly referred to as initialization, as initialization means usually setting to a sensible default value, which always is the same.
> 
>>> Maybe the term initialized is wrong and confusing. They are not initialized
>>> in the sense of having defined values as
>>> global variables have. Non-global managed types should not be considered as
>>> being initialized (never!, like any other
>>> type), this is also why the compiler warns (!) about this. They can be
>>> considered as being "setup" by the compiler.
> 
> So what does setup do - allocate memory and set refcount accordingly? 

No. Consistent in the sense that ref. counting works and causes no leaks.

> If result was being setup properly that might also help.
It is setup, but not initialized.

> 
>>>> They contain valid values and none of the internal RTL
>>>> routines will crash when used with them. Everyone however expects result
>>> variables of those to be initialized to Nil and
>>>> that is simply *not* a guaranteed given.
> 
> I'd say if everyone expects that then there is a point in that the current behaviour is surprising and not intuitive. I mean, the compiler is for people, right? ;)
> 
>>>> Also records only initialize their managed fields. All others are left as
>>> garbage.
>>>
> 
> I'm only talking about managed types.
> 
>>
>>> Managed fields of records are "setup" ;)
>>
>> I will add a section about this in the documentation, seeing that people
>> often confuse the 2 concepts.
> 
> 
> In an ideal world, either the language would not let you write code that has random behavior or the compiler would enforce this.

Compile with trunk and -Sew and you get this behavior.

> 
> Out of curiosity I did a couple of more tests and it seems FPC is pretty inconsistent in handling all this. See below.

Pretty useless code fragment.
1) This is fpc-devel and not lazarus-same-random-code, it does not compile without lazarus and even not with it.
2) If I guess the missing parts right, the example simply points out a bug of the setlength handling which is handled 
internally but this is fixed now.