[fpc-devel] Wrong docs: not initialized global variables

Michael Van Canneyt michael at freepascal.org
Thu Apr 5 08:35:05 CEST 2018



On Thu, 5 Apr 2018, Ondrej Pokorny wrote:

> On 05.04.2018 0:34, Michael Van Canneyt wrote:
>> What, because you do not agree ?
>
> No, because I didn't get any arguments against.

You did, you just don't consider them valid.

There are 2 narratives, and you choose to ignore the 2nd one.

>
>> Now, it is also correct that the compiler developers are aware that 
>> many people rely on this implementation detail.
>
> Since when is documented behavior considered as "implementation detail"? 
> This is not an implementation detail. It is in official documentation.

You and I know very well that this is an implementation detail, needed
for internal bookkeeping of the compiler. That the delphi manual states
otherwise, I have always considered a grave error on their part:
It contradicts one of the core tenets of pascal - see below.

If the compiler devs wanted, they could initialize every string with the
'<undefined string>' constant, every interface with a reference to a constant
IUnknown interface, and that would be equally correct as the current
behaviour from a compiler perspective.
(in fact, it would be an interesting test to do so. See how much code breaks)

Unfortunately, a value is needed for internal bookkeeping of the compiler. 
Which value that is, is entirely irrelevant from a compiler perspective. 
0 is simply convenient, no more, no less.

Pascal states: do not assume that variables are initialized.

That is the "rule".

>From this rule, it follows that every variable must be explicitly initialized by the
programmer at least once before using it, to have correct and predictable
behaviour: Be it with an assignment or an 'var a: type = someonstant;'.

So, if the compiler sees code that uses a variable which is not explicitly
initialized, it warns.

Simple and consequent.

That the warning has been split in 2 warnings is for your convenience. 
I suggest you put it to good use.





Michael.



More information about the fpc-devel mailing list