I get a warning that a local dynamic array variable is not initialized. Aren't such managed types initialized by default?
On http://wiki.freepascal.org/Dynamic_array it says:

Actually, dynamic arrays are pointers with automatic dereferencing. They are initialized to *nil* automatically.

So why the warning?

http://bugs.freepascal.org/view.php?id=24601#c75617 (and the comment below + use -vq to see warning numbers, and -vmXXXX to block a particular warning number).

Jonas

Thanks for the answer.
But still: Why is there such a warning for managed types at all? Dynamic arrays are initialized by default so the warning text is simply wrong. It IS initialized and the compiler knows this.

That is the same question you asked in your original mail and which is answered in the bug report comment I linked in reply.

Jonas

Not quite. In the bug comment you wrote:

The warning is by design for all kinds of variables and regardless of their storage location (as noted by the original submitter, global/static variables of any kind are always initialised by 0/nil/...). The warning means that no value has been explicitly assigned to these variables (which may indicate a logic error in the code), not necessarily that they contain an unpredictable value.

But still there is the question *why* this design exists? I think it is a bad design.
It should know that managed types *are* initialized and not raise a warning in this case. Why generate a warning with an incorrect statement? Am I forced to add (superfluous) initialization code or somehow suppress this kind of warning just to get rid of this false warnings which are useless from the beginning?

I would think this part answers that question: "The warning means that no value has been *explicitly* assigned to these variables (which *may indicate a logic error* in the code), not necessarily that they contain an unpredictable value." (emphasis mine)

Jeff.

DaWorm wrote

I would think this part answers that question: "The warning means that no value has been */explicitly/* assigned to these variables (which */may indicate a logic error/* in the code), not necessarily that they contain an unpredictable value." (emphasis mine)

No, it answer not the question.
As I already wrote in my other mail:
Why am I forced to add superfluous (initialization) code just to get rid of a warning that is completely useless (false). Managed types *are* initialized so this warning just pollutes the message window and distracts from the realy useful information.

Why not simply omit these messages (for managed types)?

Just because YOU don't need it, doesn't mean it's useless for everybody...

http://www.freepascal.org/docs-html/prog/progsu80.html#x87-860001.2.80

why not just use this to suppress the warning JUST where you DO know it's not needed?

(you can suppress warning by number too IIUC).

el es

Yes.
For example in Lazarus 1.3+ you can right click the message and click on "Hide with project option (-vm5089)".

Mattias

Cool, but probably not what I meant ;) as this hides it project-wide ?

I mean, it's good to have this warning enabled by default and only suppress it around code that /I/ know it's bogus at. Otherwise, it /really/ wouldn't serve its purpose of pointing where a PEBKAC^WLOGIC ERROR may occur...

Sort of like surround the variable declaration with
{$WARN IDENTIFIER OFF}
{$WARN IDENTIFIER ON}  explicitly (then have code tools fold it so it won't pinch our eyes ;) )

Mattias

el es

Yes. I guess that is what Jürgen wants.

I agree with you that in general the hint is good and should be handled depending on each occurrence.

Mattias

everybody...

>> >> http://www.freepascal.org/docs-html/prog/progsu80.html#x87-860001.2.80 >> >> why not just use this to suppress the warning JUST where you DO know

it's not needed?

suppress it around code

that /I/ know it's bogus at. Otherwise, it /really/ wouldn't serve its

purpose of pointing

won't pinch our eyes ;) )

Note: you should use the sequence
{$push}{$warn xyz off}bla{$pop} as otherwise you would enable the warning if it was disabled from the command line parameters or the configuration.

Regards,
Sven

Then please tell me, what do you (or anybody else) gain from this warning? Especially, as it claims something that is definitely not true (for managed types). It may even misguide some to add initialisation code without need and it distracts from the realy important messages.

Would this oppress these warnings for managed types only? Or would I loose them for non-managed types too?

Jürgen Hestermann wrote

Would this oppress these warnings for managed types only? Or would I loose them for non-managed types too?

Let me repeat myself from the very first reply I sent to you in this thread: "http://bugs.freepascal.org/view.php?id=24601#c75617 (and the comment below + use -vq to see warning numbers, and -vmXXXX to block a particular warning number)."

See in particular the referenced "comment below".

Jonas

everybody...

>> >> http://www.freepascal.org/docs-html/prog/progsu80.html#x87-860001.2.80 >> >> why not just use this to suppress the warning JUST where you DO know

it's not needed?

It mutes the warning with the ID 5089 (the ID can be seen with -vq). So as long as the managed and unmanaged ones use the same warning ID (AFAIR they do) they will both be silenced.

Regards,
Sven

everybody...

>>> >>> http://www.freepascal.org/docs-html/prog/progsu80.html#x87-860001.2.80 >>> >>> why not just use this to suppress the warning JUST where you DO know

it's not needed?

as long as the managed and unmanaged ones use the same warning ID (AFAIR they do) they will both be silenced.

*looks at the comments of the bug report again*
Ups, no, they are different. So at least if you use a current 2.7.1 or newer only the managed ones will be hidden.

Regards,
Sven

Sven Barth wrote

> It mutes the warning with the ID 5089 (the ID can be seen with -vq). So as long as the managed and unmanaged ones use the same warning ID (AFAIR they do) they will both be silenced. Ups, no, they are different. So at least if you use a current 2.7.1 or newer only the managed ones will be hidden.

Currently I use Lazarus 1.4RC1 with FPC Version 2.6.4. Does this version already have different IDs for managed and non-managed types?

Just googled this out:

http://lazarusroad.blogspot.co.uk/2014/02/using-tcomponent-with-automatic.html

and this immediately after:

http://lazarusroad.blogspot.co.uk/2012/07/cost-to-supress-warning-and-how-not-pay.html

el es

Thanks, seen this hinted on this m/l before, +1 :)

Regards, Sven

el es

Just googled this out:
(edit: meant this actually)
http://lazarusroad.blogspot.com.br/2012/07/does-it-matter-how-dynamic-arrays-are.html

and this immediately after:

http://lazarusroad.blogspot.co.uk/2012/07/cost-to-supress-warning-and-how-not-pay.html

el es

2.6.4 does not have message 5089.
It came with 2.7.1.
Luckily 3.0 is not that far away.

Mattias

I am not sure what these links should tell me.
I could not find any hint that omitting the warnings for managed types would do any harm. Just the opposite. As I already suspected, people are adding code just to get rid of the warning (or they have the time and leisure to disable these warnings for each project over and over again): Cite from the second link:

"Although the performance impact is mostly negligible, is extra code anyway. In my case i initialize the parameter explicitly so *out* would add redundant code. There's an alternative to suppress the message: add the directive {%H-} in front of the variable that is being passed to the procedure."

Again I can't find any legimitation for having these warnings.

Using dyn. arrays without initialization makes litte sense in real world programs, so those warnings have their use.

Further, automatic initialization of managed types is not something to help lazy programmer but simply needed for the compiler so it is able to handle memory management.

Last but not least, if a type is initialized manually and automatically, the compiler is supposed to remove the unnecessary ininitalization (currently it cannot do this always on all platforms though) to avoid any speed penalty.

Florian Klämpfl wrote

Using dyn. arrays without initialization makes litte sense in real world programs,

Why this? I do this all the time.
I know that they *are* already initialized
so why should I do this again?

so those warnings have their use.

Of what use are they?