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

Ondrej Pokorny lazarus at kluug.net
Thu Apr 5 00:20:01 CEST 2018

On 04.04.2018 21:51, Jonas Maebe wrote:
> On 04/04/18 20:26, Ondrej Pokorny wrote:
>> The compiler initializes the variable implicitely for myself - this 
>> is documented and I know it. There cannot be "wrong code behaviour" 
>> (as you stated) and thus I cannot have an error. This is simple logic.
> "Wrong behaviour" is not the same as "undefined behaviour" or "crash". 
> It merely means "something different than the programmer intended". It 
> is of course possible that you wanted the behaviour that you get when 
> the variable contains the empty string, nil or 0, but because this 
> initialisation is implicit rather than explicit, the compiler does not 
> rely on this. After all, it is equally possible that you forgot to 
> assign the correct (non-nil/0/empty string) value to the variable 
> before using it the first time (in which case it would be an error in 
> the program).

How can I forget to assign the correct (non-nil/0/empty string) value to 
a variable? Oh god, this is such a crazy argument - completely out of 
the reality. At latest the first execution of the program tells me about 
this error. Warnings should warn me about possible errors that I cannot 
easily find and that are potentially dangerous.

No, this discussion is useless.

>> I must not. Turning off warnings is forbidden. Turning off hints and 
>> notes is OK. That is the rules. 
> The inflexibility of that rule in the Lazarus project is not a good 
> reason to change the priority of the message.

...and the difference between a "truly uninitialized variable" and an 
"implicitely initialized variable" is not a reason either...

Funnily enough there are both message levels (warning and hint) for all 
variants of "not explicitely initialized variable". So somebody decided 
when a hint and when a warning is emitted and you seem to be convinced 
this decision is engraved in stone.

Even more funny - in 
https://bugs.freepascal.org/view.php?id=24601#c75617 you used the same 
tactics as now - you explain in a general way what the current behavior 
is and ignore arguments for a possible change to make the behavior 
clearer. Later, Florian changed it himself.


More information about the fpc-devel mailing list