On Thu, 5 Apr 2018, Ondrej Pokorny wrote:

On 05.04.2018 8:35, Michael Van Canneyt wrote:
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.

Huh, no, I don't know this is an implementation detail. For me the initialization rules always were:

1.) Global variables are initialized. (Why is simple global variables initialization needed for internal bookkeeping of the compiler?) 2.) Class fields are initialized. (Why is simple class fields initialization needed for internal bookkeeping of the compiler?)
3.) Everything else is not initialized.

Very well done :)

You explained exactly why I think the delphi docs are wrong.

If delphi wanted to do things correctly and consistently they would simply say 'everything is initialized to 0'. Period.

Simple, consistent, easy.

The above is a kludge.

The point of view of 'Pascal' is that you should consider every variable uninitialized.

Simple, straightforward.

Instead, Delphi elevates some arbitrary implementation details to 'rule'
with the above kludge as a result.

It means you count on things which the delphi developer of that day decided to
implement. Maybe because he  was drunk. Maybe he was under the influence of
drugs. Maybe because he decided that the 0 key "looks kinda nice". or simply
because he by accident used a section in the binary that the OS just happens to guarantee to be 0. We don't know. But this accidental behaviour
unfortnately made it in the docs.

We'll just have to live with it, it seems.

fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Reply via email to