Will global variables and static global arrays be always initialized to zero? It seems that they in fact are, and there is quite a lot of code relying on it. On the other hand, the documentation denies that. What is the official position?

Alexander Klenin wrote

Will global variables and static global arrays be always initialized to zero?

Yes.

Jonas

Then I suggest to amend the first paragraph of
http://www.freepascal.org/docs-html/ref/refse22.html which directly contradicts this.

I have rather curious story behind this request.
In Russia, schoolchildren must pass "Unified State Exam" ("ЕГЭ" in russian) upon graduation.
The exam on informatics includes requirement to write a simple program. Currently, the program is allowed to be written in any programming language, but it is written on paper, the pupil must precisely specify the language, and the program is graded manually by teachers.

Some pupils wrote in Free Pascal, which is moderately popular in schools (something around 20% IIRC). Several of them omitted initialization of global arrays
based on the assumption that they will be zeroed automatically. Those pupils were failed for that, and the graders stated that even if current implementation
happens to zero global variables, this is not documented and so is merely an implementation artifact which must not be relied upon.

Hence, this omission resulted in lower grades for some schoolchildren.

It does not directly contradict this ?

For local variables the statement is 100% correct. You must initialize local variables.

For global variables, it's a different story.

The last time that this discussion popped up - exactly 3 years ago in fpc-pascal - there was some confusion as to what is now exactly behaviour and what is spec for global variables.

From what I can see in the archives, the FPC behaviour is to zero out

because Delphi and TP do so. The Pascal spec is not to assume that it is zeroed out.

So, based on the specs, the teachers are right.
Based on docs as they are now, they are also right.

The docs does not specifically say something about the difference between global and local variables. (unless I've missed it)

But I will amend the docs.

Michael.

Alexander Klenin wrote / napísal(a):

Very nice story!
-Laco.

Are there cases where locals are set to a sane initial state, e.g. for strings and dynamic arrays? What about (references to) objects?

Managed types are normally initialized. That means Ansistrings, UnicodeString, and COM interfaces and dynamic arrays (maybe I forget some)

Classes and objects are not. I am not sure about widestrings on Windows.

But again, not always:

For instance

Function a(B : Integer) : Ansistring;
begin
   Result:=Result+' something';
end;

You would think that Result is initialized because it is managed: it is an ansistring. In fact, it is not initialized, leading sometimes to surprises.

I only learned about this relatively recently, much to my surprise.

It is one of the reasons I am reluctant to document this in detail, there always seem to pop up new cases.

In general, you are safer off by assuming that nothing is initialized. Initializing it again does no damage.

Michael.

By which I presume that (references to) objects are not set to nil, in the same way that an integer or pointer wouldn't be set to zero or nil.

Yes.

Michael.

I'd expect that the Result is passed in as a reference, which is initialized before the call. Just like record results are handled.

DoDi

Apologies for revisiting an old thread.

Looking at this code:

function WagnerFischerBestMatch(const pattern: string; stringList:
TStringList): integer;
var	scratch: StringArray;	// array of string;
	i: integer;
begin
   for i := 0 to stringList.Count - 1 do
     scratch += stringList[i];

where + has been defined to append an element to the array, I get a warning that scratch hasn't been initialised. Similarly

function singleRadioGroup(items: TMenuItem): string;
var     i: integer;
         gi: integer= 0;
         name, firstName, checkedName: string;
begin
..
         if firstName = '' then

In view of what you said about managed types, is it safe to assume that the error message is spurious? I'm a little reluctant to add an explicit e.g. SetLength(scratch, 0) or to break the string declarations onto separate lines simply to suppress a warning, when it isn't necessary for correctness.

I note the fairly recent introduction of {%H- } to tell Lazarus to filter out specific warnings.

The teachers were correct. A program's correctness stands purely on the states defined by the meaning of its texts, not on some compiler behaviour or some execution or implementation model. The teachers are at fault here. I don't suppose they understand that themselves, as the students wouldn't err if the teachers impressed that principle before the test. The graders were right but for the wrong reasons.

In the pure sense defined by the meaning of the texts the initial states are undefined if the variables are not expressly initialized.

"We must learn to work with program texts while (temporarily) ignoring that they admit the interpretation of executable code." http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html. As some of you might suspect I am a fan of the late Edsger Dijkstra, That paper is a bit of a (quite justified) rant but some of the issues are covered in his other papers, but it has taken me some time to begin to grok the foundations of his perspective.

I am also not that good a programmer. :-(