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

[Bart]

On Thu, Apr 5, 2018 at 4:22 PM, Karoly Balogh (Charlie/SGR)
 wrote:


> But again, it's zeroed out, not really "initialized". So for example if
> you have a type with say, 5..7 value range, it will still contain zero
> after start. Hence, uninitialized, therefore the warning is correct. (See
> below for examples.)

Never realized this...


> type
>   qq = (foo, bar, klepp, mopp, fubb);
>   q = klepp..fubb;
>
> var
>   c: q;
>
> begin
>   writeln(ord(c)); // will write 0;
>   writeln(c); // will fail with runtime error (out of range)
> end.
>
>
> And:
>
> {$MODE OBJFPC}
>
> type
>   qq = (foo, bar, klepp, mopp, fubb);
>   q = klepp..fubb;
>
> type
>   clfoo = class
> c: q;
>   end;
>
> var
>   x: clfoo;
>
> begin
>   x:=clfoo.create;
>   writeln(ord(x.c)); // write 0;
>   writeln(x.c); // runtime error (out of range)
> end.
>
> Tested with FPC 3.0.4 32bit on macOS.
>
> I'd be interesting to know if Delphi behaved otherwise.

D7 behaves the same, except that in the 2nd example the line
writeln(x.c) cannot be compiled, so I could not test that, but the
line above prints 0.

Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Jonas Maebe]

On 05/04/18 17:18, Michael Van Canneyt wrote:

On Thu, 5 Apr 2018, Martok wrote:


Am 05.04.2018 um 08:35 schrieb Michael Van Canneyt:

If the compiler devs wanted, they could initialize every string with the
'' constant,

That is in fact the -gt option.


I doubt -gt does something for managed types?


It does not, except for managed string results (because those are not 
guaranteed to be empty by Delphi either).



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Michael Van Canneyt]

On Thu, 5 Apr 2018, Martok wrote:


Am 05.04.2018 um 08:35 schrieb Michael Van Canneyt:

If the compiler devs wanted, they could initialize every string with the
'' constant,

That is in fact the -gt option.


I doubt -gt does something for managed types?




Pascal states: do not assume that variables are initialized.

Corollary: there is no guarantee that "class operator Initialize()" is ever
called, and Maciej can roll back management operators. I very much doubt this is
what you want to imply.


And why not ?

This is the whole problem and source of the "kludge' I referred to:

When introducing managed types, Delphi should have performed the full monty, 
and simply zero-out everything at any point.


This would eliminate in large part the need for management operators, since
you can then detect whether a type is initialized or not if so desired, and
act on it.

TMyManagedType = Record
  IsInitialized : Boolean;
  // The rest of what you actually need
end;


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Sven Barth via fpc-devel]

Martok  schrieb am Do., 5. Apr. 2018, 16:29:

> > From this rule, it follows that every variable must be explicitly
> initialized [...]
> > Be it with an assignment or an 'var a: type = someonstant;'.
> ... for which the syntactic sugar was rejected not two weeks ago.
>

Did we read the same thread?

"var a: type = x" is already supported for both global and local variables
and Florian agreed that there is no reason to restrict that only to a
single variable (but only with the same value for each).
Okay, Jonas disagreed, but personally am in favor of allowing that as well.

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martok]

Am 05.04.2018 um 08:35 schrieb Michael Van Canneyt:
> If the compiler devs wanted, they could initialize every string with the
> '' constant,
That is in fact the -gt option.

> Pascal states: do not assume that variables are initialized.
Corollary: there is no guarantee that "class operator Initialize()" is ever
called, and Maciej can roll back management operators. I very much doubt this is
what you want to imply.
To preempt the argument - no, this is not a different case. Managed types are
initialized at the latest when they come into scope, period.

> From this rule, it follows that every variable must be explicitly initialized 
> [...]
> Be it with an assignment or an 'var a: type = someonstant;'.
... for which the syntactic sugar was rejected not two weeks ago.



To the people referring to Borland Language Guides: As I painfully discovered,
the Borland guides are *not* considered normative material for FPC by certain
FPC developers. Not even for -Mtp.
For some reason, ISO 7185 *is* a reference, even for decidedly not-ISO modes.

Am 05.04.2018 um 12:47 schrieb Alexander Klenin:
> Allow me to yet again to single out this philosophy of
> strongly preferring abstract purity to concrete user experience.
If it at least was consistent purity!

Sorry. Needed to be said.


-- 
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Karoly Balogh (Charlie/SGR)]

Hi,

Just some technical background to this discussion, I don't care who
documented what, I'm just stating how it works. :P

On Thu, 5 Apr 2018, Ondrej Pokorny 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.

The Delphi manual probably states the de-facto behavior. You cannot not
initialize global variables to zero on most modern Un*ces and Windows,
because the OS will zero out the bss section on executable loading, which
is where most global variables live. (Unless they're in the data section,
in which case they have a specified initial value, but that's more like
typed consts with an initial value in Pascal's context.)

But again, it's zeroed out, not really "initialized". So for example if
you have a type with say, 5..7 value range, it will still contain zero
after start. Hence, uninitialized, therefore the warning is correct. (See
below for examples.)

> 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?)

As I wrote above, we cannot not "initialize" (as in: zero out) the global
variables on modern systems, because the compiler doesn't do it, but the
executable loader of the OS. (Well, it's actually a bit more complicated,
if threadvars are involved, but that's platform specific what happens
there, and the end result is the same - global variables are zeroed out.)

> 2.) Class fields are initialized. (Why is simple class fields
> initialization needed for internal bookkeeping of the compiler?)

I think this is something which happens when constructing the class, so
this is runtime behavior, and not compile or exe loading time, and again,
it's just clearing the allocation after GetMem()'ing the heap area for
the class, so you don't get trash in the fields. But they're don't
necessarily initialized to valid values (if zero is not valid).

> 3.) Everything else is not initialized.

> Yes, I have always relied on both 1.+2. For me both points 1.+2. are
> well documented and wanted behavior. Isn't it so?

Do you want initialized, or zeroed out? Zero out will happen,
initialization will not:

Take these two examples:

type
  qq = (foo, bar, klepp, mopp, fubb);
  q = klepp..fubb;

var
  c: q;

begin
  writeln(ord(c)); // will write 0;
  writeln(c); // will fail with runtime error (out of range)
end.


And:

{$MODE OBJFPC}

type
  qq = (foo, bar, klepp, mopp, fubb);
  q = klepp..fubb;

type
  clfoo = class
c: q;
  end;

var
  x: clfoo;

begin
  x:=clfoo.create;
  writeln(ord(x.c)); // write 0;
  writeln(x.c); // runtime error (out of range)
end.

Tested with FPC 3.0.4 32bit on macOS.

I'd be interesting to know if Delphi behaved otherwise. But in the above
case the compiler warning about uninitialized variable is completely
valud, even if it's not random but initialized to zero due to OS and RTL
behavior.

Charlie
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Ched]

Hello,

Le 05.04.2018 à 11:55, Marco van de Voort a écrit :

In our previous episode, Alexander Klenin said:

>>

Allow me to yet again to single out this philosophy of
strongly preferring abstract purity to concrete user experience.
This is IMHO a significant contributing factor of Pascal decline.


No. Not having something that creates new users is the main reason.

IN-OUT<0

In general, the assumption that the popularity of a development product
is mainly dependent on language is already faulty.


Hélas, the language which is currently gaining popularity is Python. Even Java 
is loosing popularity.
But Python is not compiled and not suited for large programs (my own opinion). I rest with my favourite 
language : (Free)Pascal :)


https://www.tiobe.com/tiobe-index/
https://pypl.github.io/PYPL.html?country=FR

Cheers, Ched'
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Marco van de Voort]

In our previous episode, Alexander Klenin said:
> > Simple, straightforward.
> >
> Allow me to yet again to single out this philosophy of
> strongly preferring abstract purity to concrete user experience.
> This is IMHO a significant contributing factor of Pascal decline.

No. Not having something that creates new users is the main reason.

IN-OUT<0

In general, the assumption that the popularity of a development product
is mainly dependent on language is already faulty.

> I would not argue this specific point (although I quite agree with Ondrej),
> I just want to remind that the cost in terms of diminishing userbase
> is real, and that makes me sad.

I'm with Michael. 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Michael Van Canneyt]

On Thu, 5 Apr 2018, Alexander Klenin wrote:


On Thu, Apr 5, 2018 at 10:24 AM, Michael Van Canneyt
 wrote:


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.


Allow me to yet again to single out this philosophy of
strongly preferring abstract purity to concrete user experience.


Stop:

I am not preferring anything.

I'm just pointing out that the current situation is a kludge, it is the
consequence of some ill-advised pragmatism on the part of
Borland/embarcadero/inprise/Codegear.

If it is decided to simply zero out *all* variables - which is a decision based 
on a principle and as such an 'abstract purity' - you will not hear me complain.

(Why do you think I mentioned it in the first place ?)

Such a decision may well be beneficial for the user experience.

But until that time, the warning as issued by the compiler is correct,
consequent and in the philosphy of the language, and that is what the 
discussion is about.


Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin Schreiber]

On Thursday 05 April 2018 12:47:27 Alexander Klenin wrote:
>
> Allow me to yet again to single out this philosophy of
> strongly preferring abstract purity to concrete user experience.
> This is IMHO a significant contributing factor of Pascal decline.
> I would not argue this specific point (although I quite agree with Ondrej),
> I just want to remind that the cost in terms of diminishing userbase
> is real, and that makes me sad.

Agreed 100%.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Alexander Klenin]

On Thu, Apr 5, 2018 at 10:24 AM, Michael Van Canneyt
 wrote:
>
> 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.
>
Allow me to yet again to single out this philosophy of
strongly preferring abstract purity to concrete user experience.
This is IMHO a significant contributing factor of Pascal decline.
I would not argue this specific point (although I quite agree with Ondrej),
I just want to remind that the cost in terms of diminishing userbase
is real, and that makes me sad.

-- 
Alexander S. Klenin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Nikolai Zhubr]

Hi,

05.04.2018 10:12, Ondrej Pokorny пишет:
[...]

1.) Global variables are initialized. (Why is simple global variables
initialization needed for internal bookkeeping of the compiler?)


IIRC this was historically introduced by Borland (ages ago) because it 
was very cheap and easy to ask an OS of their choice to zero-out .data 
segment upon executable module loading, effectively getting 
initialization for free, and at that time (ages ago!) speed was what 
they cared most about.



2.) Class fields are initialized. (Why is simple class fields
initialization needed for internal bookkeeping of the compiler?)


Here again, it was relatively cheap and easy to fillchar/memset object's 
body internally before use. Not competely free, but pretty efficient 
still. So essentially same reason, I'd say.



3.) Everything else is not initialized.


Apparently this was not so cheap and not so easy for Borland (at least 
at that time). So apparently they chose to ignore.



From my personal perspective, this indeed is implementation detail, 
however wildely abused (me included), and it is a rather unfortunate 
situation. E.g. I'd be in a huge disaster if implicitely initialized 
strings suddenly start to be '' instead of empty. 
So ideally, something clever should be done about it at some point. 
Maybe indeed declaring it as a guaranteed behaviour or something. I kind 
of doubt there is a realistic chance of changing it anyway, due to 
compatability reasons...



Thank you.

Regards,
Nikolai
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Michael Van Canneyt]

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.

Michael.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Ondrej Pokorny]

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.

Yes, I have always relied on both 1.+2. For me both points 1.+2. are 
well documented and wanted behavior. Isn't it so?


About point 3: your very own docs state otherwise for managed types (see 
my initial email in this thread) and I was surprised to read it. I am 
not aware the Delphi manual states anything about initializing managed 
types. AFAIK Delphi manual states that the compiler itself cares about 
memory management automatically but it doesn't state anything about when 
initialization or finalization must happen. It doesn't state local 
managed variables are initialized to empty string/nil in particular.


Until now I have never relied on implicitely initialized local 
variables. Your very own docs document the guaranteed local managed 
variable initialization, not Delphi's. If you say it is an 
implementation detail, you must delete it from the docs. For me the 
"grave error" is on FPC's side and not Delphi's.


Ondrej
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Michael Van Canneyt]

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
'' 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.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel