On 07.07.2018 10:54, Florian Klämpfl wrote:
Am 07.07.2018 um 08:18 schrieb Ondrej Pokorny:
As you see, all messages are hints only, no warnings. Regardless of
managed/not-managed global/local variable.
There are a lot of exceptions when which warning happens, try the same
with e.g. writel
Am 07.07.2018 um 08:18 schrieb Ondrej Pokorny:
As you see, all messages are hints only, no warnings. Regardless of
managed/not-managed global/local variable.
There are a lot of exceptions when which warning happens, try the same with e.g. writeln and the file parameter (just
one of these ex
Am 07.07.2018 um 08:05 schrieb Ondrej Pokorny:
makes me feel I have been always right in this thread...
Fine, so we can close the case.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-
On 03.07.2018 19:53, Stefan Glienke wrote:
SetLength should not cause anything uninitialized.
No, SetLength is not documented to clear the new initialized memory
block so the new memory block can contain whatever you want.
It is documented not to touch the existing memory block in the array.
On 07.07.2018 08:05, Ondrej Pokorny wrote:
On 03.07.2018 22:08, Florian Klämpfl wrote:
Am 03.07.2018 um 21:30 schrieb Ondrej Pokorny:
On 03.07.2018 20:54, Florian Klämpfl wrote:
program Project1;
type
TMyArray = array[0..10] of Integer;
procedure Init2(var A: TMyArray);
begin
A[2]
On 03.07.2018 22:08, Florian Klämpfl wrote:
Am 03.07.2018 um 21:30 schrieb Ondrej Pokorny:
On 03.07.2018 20:54, Florian Klämpfl wrote:
program Project1;
type
TMyArray = array[0..10] of Integer;
procedure Init2(var A: TMyArray);
begin
A[2] := 1;
end;
var
A: TMyArray;
begin
On 04.07.2018 12:08, Yuriy Sydorov wrote:
Remove the warning or change it to a note in such case.
Earlier in this thread I tried to convince the FPC team to downgrade the
warning to a note. Without success. I was told that there is is no "good
reason to change the priority of the message".
On Wed, 4 Jul 2018, Yuriy Sydorov wrote:
On 7/4/2018 12:09 AM, Florian Klämpfl wrote:
Am 03.07.2018 um 22:57 schrieb Ondrej Pokorny:
Probably I am the only one who thinks that the code below is ridiculous...
procedure TExternalAssemblerOutputFile.AsmWriteFiltered(p: pchar;
len: longi
On 7/4/2018 12:09 AM, Florian Klämpfl wrote:
Am 03.07.2018 um 22:57 schrieb Ondrej Pokorny:
Probably I am the only one who thinks that the code below is ridiculous...
procedure TExternalAssemblerOutputFile.AsmWriteFiltered(p: pchar; len:
longint);
var
s: ansistring;
Am 04.07.2018 um 00:00 schrieb Nikolay Nikolov:
So, even though filling objects with zero introduces a small runtime
overhead, it saves a lot of pain and prevents difficult to find bugs
(people quite often don't test exceptions raised in the constructor).
And I don't know how often I've been bit
> > Probably I am the only one who thinks that the code below is
> ridiculous...
> >
> > procedure TExternalAssemblerOutputFile.AsmWriteFiltered(p:
> pchar;
> > len: longint);
> >var
> > s: ansistring;
> >begin
> > MaybeAddLinePrefix;
> > s:=''; // <<
On 03.07.2018 23:09, Florian Klämpfl wrote:
Am 03.07.2018 um 22:57 schrieb Ondrej Pokorny:
On 03.07.2018 22:08, Florian Klämpfl wrote:
Am 03.07.2018 um 21:30 schrieb Ondrej Pokorny:
On 03.07.2018 20:54, Florian Klämpfl wrote:
program Project1;
type
TMyArray = array[0..10] of Integer;
pro
On 04/05/2018 05:22 PM, Karoly Balogh (Charlie/SGR) wrote:
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
Ondrej Pokorny schrieb am Di., 3. Juli 2018, 22:57:
> On 03.07.2018 22:08, Florian Klämpfl wrote:
> > Am 03.07.2018 um 21:30 schrieb Ondrej Pokorny:
> >> On 03.07.2018 20:54, Florian Klämpfl wrote:
> >> program Project1;
> >> type
> >>TMyArray = array[0..10] of Integer;
> >>procedure Init
Am 03.07.2018 um 22:57 schrieb Ondrej Pokorny:
On 03.07.2018 22:08, Florian Klämpfl wrote:
Am 03.07.2018 um 21:30 schrieb Ondrej Pokorny:
On 03.07.2018 20:54, Florian Klämpfl wrote:
program Project1;
type
TMyArray = array[0..10] of Integer;
procedure Init2(var A: TMyArray);
begin
On 03.07.2018 22:08, Florian Klämpfl wrote:
Am 03.07.2018 um 21:30 schrieb Ondrej Pokorny:
On 03.07.2018 20:54, Florian Klämpfl wrote:
program Project1;
type
TMyArray = array[0..10] of Integer;
procedure Init2(var A: TMyArray);
begin
A[2] := 1;
end;
var
A: TMyArray;
begin
Am 03.07.2018 um 21:30 schrieb Ondrej Pokorny:
On 03.07.2018 20:54, Florian Klämpfl wrote:
The warning happens also for any other call which takes an uninitialized variable as var parameter (see e.g.
fillchar). So the warning increases only orthogonality of the language. It was an oversight that
On 03.07.2018 20:06, Martin wrote:
On 03/07/2018 19:27, Ondrej Pokorny wrote:
On 7/3/2018 9:40 AM, Ondrej Pokorny wrote:
program Project1;
var
S: string;
begin
SetLength(S, 10); // <<< warning here --->> WHY
Writeln(S[2]); // <<< no warning here --->> WHY
end.
The comp
On 03.07.2018 20:54, Florian Klämpfl wrote:
The warning happens also for any other call which takes an
uninitialized variable as var parameter (see e.g. fillchar). So the
warning increases only orthogonality of the language. It was an
oversight that it not was thrown before.
This is correct i
Am 03.07.2018 um 20:46 schrieb Ondrej Pokorny:
On 03.07.2018 19:53, Stefan Glienke wrote:
SetLength should not cause anything uninitialized.
It enlarges or shrinks the data and keeps any prior data as it was, new allocated memory is zeroed (at least that is
how it works in the Delphi RTL and I
On 03.07.2018 19:53, Stefan Glienke wrote:
SetLength should not cause anything uninitialized.
It enlarges or shrinks the data and keeps any prior data as it was, new
allocated memory is zeroed (at least that is how it works in the Delphi RTL and
I would be very surprised if FPC would do any di
On 03/07/2018 19:27, Ondrej Pokorny wrote:
On 7/3/2018 9:40 AM, Ondrej Pokorny wrote:
program Project1;
var
S: string;
begin
SetLength(S, 10); // <<< warning here --->> WHY
Writeln(S[2]); // <<< no warning here --->> WHY
end.
The compiler tells me that the line "SetLeng
SetLength should not cause anything uninitialized.
It enlarges or shrinks the data and keeps any prior data as it was, new
allocated memory is zeroed (at least that is how it works in the Delphi RTL and
I would be very surprised if FPC would do any different).
The core issue imo is temp var reu
On 03.07.2018 19:00, Ralf Quint wrote:
On 7/3/2018 9:40 AM, Ondrej Pokorny wrote:
1.) SetLength itself produces an unitialized block of data within the
variable if the new length is bigger than the old length.
Therefore it would be more appropriate to get an "uninitialized
warning" after SetLen
On 7/3/2018 9:40 AM, Ondrej Pokorny wrote:
>
> 1.) SetLength itself produces an unitialized block of data within the
> variable if the new length is bigger than the old length.
>
> Therefore it would be more appropriate to get an "uninitialized
> warning" after SetLength:
>
> program Project1;
> va
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.
"Wron
On 05.04.2018 17:10, Sven Barth via fpc-devel wrote:
Martok mailto:list...@martoks-place.de>>
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;'.
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
> belo
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 ty
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 va
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
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 Initial
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.
> >
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
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
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.
Sim
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 (altho
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
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
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
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
d
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
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.
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
On Thu, 5 Apr 2018, Ondrej Pokorny wrote:
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 canno
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.
"Wron
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 "undefine
https://www.freepascal.org/docs-html/ref/refse20.html#x50-680003.9
On 04/04/2018 01:32 PM, Ondrej Pokorny wrote:
On 04.04.2018 18:53, Jonas Maebe wrote:
On 04/04/18 18:44, Ondrej Pokorny wrote:
I want to stress that the compiler emits a warning on code that does
not have (and also cannot have
On 04.04.2018 20:03, Jonas Maebe wrote:
On 04/04/18 19:32, Ondrej Pokorny wrote:
On 04.04.2018 18:53, Jonas Maebe wrote:
On 04/04/18 18:44, Ondrej Pokorny wrote:
I want to stress that the compiler emits a warning on code that
does not have (and also cannot have) an error
An error is wrong co
On 04/04/18 19:32, Ondrej Pokorny wrote:
On 04.04.2018 18:53, Jonas Maebe wrote:
On 04/04/18 18:44, Ondrej Pokorny wrote:
I want to stress that the compiler emits a warning on code that does
not have (and also cannot have) an error
An error is wrong code behaviour. If you do not initialise a
On 04.04.2018 18:53, Jonas Maebe wrote:
On 04/04/18 18:44, Ondrej Pokorny wrote:
I want to stress that the compiler emits a warning on code that does
not have (and also cannot have) an error
An error is wrong code behaviour. If you do not initialise a variable
with the correct value, then you
On 04/04/18 18:44, Ondrej Pokorny wrote:
I want to stress that the compiler emits a warning on code that does not
have (and also cannot have) an error
An error is wrong code behaviour. If you do not initialise a variable
with the correct value, then you can have an error. This correct value
c
On 04.04.2018 17:49, Jonas Maebe wrote:
On 04/04/18 10:47, Ondrej Pokorny wrote:
I would lower the level of notification for "trivial: string" to a
hint. It is nonsense to emit the same level of notification (warning)
for dangerous code ("serious: integer") and valid code ("trivial:
string").
On 04/04/18 10:47, Ondrej Pokorny wrote:
I would lower the level of notification for "trivial: string" to a hint.
It is nonsense to emit the same level of notification (warning) for
dangerous code ("serious: integer") and valid code ("trivial: string").
Warnings are something to care about, th
On 25.03.2018 16:28, Jonas Maebe wrote:
On 2018-03-25 00:09, Ondrej Pokorny wrote:
Why do I get the compiler warning when the variable is indeed
guaranteed to be initialized to nil/empty string?
https://bugs.freepascal.org/view.php?id=24601
Very good bug report.
I would lower the level of n
On 2018-03-25 00:09, Ondrej Pokorny wrote:
I found the source of my assumption, I get a compiler warning in this
case:
program StringsTest;
function Test: string;
var S: string;
begin
S := S + 'a';
Result := S;
end;
begin
Writeln(Test);
end.
Emits:
StringsTest.lpr(5,8) Warning: Local vari
On Sat, 24 Mar 2018, Ondrej Pokorny wrote:
On 24.03.2018 23:00, Sven Barth via fpc-devel wrote:
Ondrej Pokorny mailto:laza...@kluug.net>> schrieb am
Sa., 24. März 2018, 20:49:
This is not correct. Global simple variables are always
initialized. At
least in Delphi it is so:
h
On 24.03.2018 23:33, Ondrej Pokorny wrote:
Another question about this sentence in FPC docs: "Managed types are
always initialized: in general this means setting the reference
count to
zero, or setting the pointer value of the type to Nil."
Does it mean I can assume a local
On 24.03.2018 23:00, Sven Barth via fpc-devel wrote:
Ondrej Pokorny mailto:laza...@kluug.net>> schrieb
am Sa., 24. März 2018, 20:49:
This is not correct. Global simple variables are always
initialized. At
least in Delphi it is so:
http://docwiki.embarcadero.com/RADStudio/Tokyo/e
2018-03-24 20:49 GMT+01:00 Ondrej Pokorny :
> Does it mean I can assume a local string variable is always (=whenever the
> routine is called) initialized to ''? I.e. that TestB always returns 'a'?
>
> function TestB: string;
> var B: string;
> begin
> B := B + 'a';
> Result := B;
> end;
>
> Un
Ondrej Pokorny schrieb am Sa., 24. März 2018, 20:49:
> This is not correct. Global simple variables are always initialized. At
> least in Delphi it is so:
> http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Variables_(Delphi) "If
> you do not explicitly initialize a global variable, the compiler
Due to the "Multiple variable initialization" thread I took a look into
FPC documentation: https://www.freepascal.org/docs-html/ref/refse24.html
There it says:
By default, simple variables in Pascal are not initialized after their
declaration. Any assumption that they contain 0 or any other de
61 matches
Mail list logo
