[fpc-pascal] A warning when Blockwriting/reading dynamic array pointers

[Jürgen Hestermann]

 >> I would never expect an assignmet to nil changing anything else than 
just the value of the pointer. And for (all?) other pointers this 
expectation is valid.
 > That expectation is not valid for any reference counted type (be it a 
dynamic array, ansistring, unicodestring, COM-style interfaces). That's 
the whole point of reference counted types: they keep track of how many 
references still exist to the data, and once that reaches zero the data 
is freed.

But I just assign a value to a pointer, then I expect it to do just 
that: Assign a nil to the pointer. This should be low level and not 
create any side effects. Of course, SetLength(0) should take care of 
references etc. but not a simple assignment. It's ignoring the will of 
the programmer.

 >> No. Be aware that my dyn array pointer is part of a larger record 
structure which I blockwrite/-read to and from file. When I read back 
the structure the pointer is not valid. It's just the pointer at the 
time I wrote the file (could be months ago). Now I have to rebuild the 
stucture again. To do this I have to the pointer to nil so that 
following calls to SetLength have the correct assumption that no data 
has been allocated yet.
 > The correct way to do so is to call initialize() on the field.

It's not mentioned in the documentation you refered to 
(http://www.freepascal.org/docs-html/ref/refsu15.html#x39-450003.3.1). 
And I don't need any other routine because fillchar does the job. The 
irritation just was, that I expected an assignment to nil doing exactly 
the same as fillchar(..,#0). And I am still astonished that it does 
more. What other traps are lurking under the hood? It's hard to program 
if you have to fight with undocumented "features" instead of 
concentrating on my own mistakes...