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
17 matches
Mail list logo