Philosophical arguments aside, I filed a bug against the documentation,
since one thing is clear-- that I and others were previously misled into
believing something that is not true.
http://mantis.freepascal.org/view.php?id=30321
In the report, I included several references where the documenta
On 26.06.2016 18:20, Jürgen Hestermann wrote:
> Am 2016-06-26 um 14:13 schrieb Sven Barth:
>> But also no word that it is true either, cause you're not declaring a
> variable for the Result.
>
> Of course I am declaring a variable:
>
> function X : String;
>
> Now the (local) variable "Result" i
Hi,
On Sun, 26 Jun 2016, Jürgen Hestermann wrote:
> Am 2016-06-26 um 14:27 schrieb Karoly Balogh (Charlie/SGR):
> > There's no exception. At least not specifically for Result. It is simply
> > variable passed by reference from the caller side, therefore it's not
> > initialized inside the functio
Hi,
On 26/6/2016 7:20 μμ, Jürgen Hestermann wrote:
And because it is a manged type I could rely on the documentation
which says that managed types are initialized (with zero length/nil).
"Result" is used in the same way as a (local) variable.
What should make me think that it is different?
as
Am 2016-06-26 um 14:27 schrieb Karoly Balogh (Charlie/SGR):
> There's no exception. At least not specifically for Result. It is simply
> variable passed by reference from the caller side, therefore it's not
> initialized inside the function.
You mean when I have the following:
--
Am 2016-06-26 um 14:13 schrieb Sven Barth:
> But also no word that it is true either, cause you're not declaring a
variable for the Result.
Of course I am declaring a variable:
function X : String;
Now the (local) variable "Result" is of type "String".
I use it in the same way as any other loc
On Sunday 26 June 2016 12:09:58 Jc3bcrgen Hestermann wrote:
>
> The only exception (at least since FPC 3) is the function result
> which is totally unexpected.
> Why such an exception?
>
I don't think one could treat a function result as a normal local variable.
The reason why not to initialise th
Hi,
On Sun, 26 Jun 2016, Jürgen Hestermann wrote:
Ok, scrap what I wrote before... :|
You are right about the managed types initialization. But then the
documentation needs to be corrected there too. But actually, result is not
a local var, but in fact a "special" parameter of the function. My b
Am 26.06.2016 12:10 schrieb "Jürgen Hestermann" :
>
> Am 2016-06-26 um 01:19 schrieb Karoly Balogh (Charlie/SGR):
> > No. Local variables are not initialized by default. Managed type or not,
> > doesn't make a difference.
>
> This is not true.
> Local variables of managed types are of course initia
On 26/06/16 11:09, Jürgen Hestermann wrote:
Am 2016-06-26 um 01:19 schrieb Karoly Balogh (Charlie/SGR):
No. Local variables are not initialized by default. Managed type or not,
doesn't make a difference.
This is not true.
Local variables of managed types are of course initialized!
If you decla
Am 2016-06-26 um 01:19 schrieb Karoly Balogh (Charlie/SGR):
> No. Local variables are not initialized by default. Managed type or not,
> doesn't make a difference.
This is not true.
Local variables of managed types are of course initialized!
If you declare
var S : String;
then it is of course i
Hi,
On Sat, 25 Jun 2016, Jürgen Hestermann wrote:
> This has definitely changed with Free Pascal 3 as my programs suddenly
> did not work anymore and I had to add Setlength() all over my code.
> Before we could rely on that managed types where always initialized
> (well, that's the purpose of man
Am 25.06.2016 13:17 schrieb "Jürgen Hestermann" :
>
> Am 2016-06-25 um 09:23 schrieb Maciej Izak:
> > 2016-06-25 5:19 GMT+02:00 Michalis Kamburelis :
> > They were never guaranteed to be initialized to nil.
> > Result has special logic for string, dynamic array, method pointer and
variant (well
Am 2016-06-25 um 09:23 schrieb Maciej Izak:
> 2016-06-25 5:19 GMT+02:00 Michalis Kamburelis :
> They were never guaranteed to be initialized to nil.
> Result has special logic for string, dynamic array, method pointer and
variant (well documented ;) ):
> "For a string, dynamic array, method p
Am 25.06.2016 09:23 schrieb "Maciej Izak" :
>
> 2016-06-25 5:19 GMT+02:00 Michalis Kamburelis :
>>
>> They were never guaranteed to be initialized to nil.
>
>
> Result has special logic for string, dynamic array, method pointer and
variant (well documented ;) ):
>
> "For a string, dynamic array, me
2016-06-25 5:19 GMT+02:00 Michalis Kamburelis :
> They were never guaranteed to be initialized to nil.
>
Result has special logic for string, dynamic array, method pointer and
variant (well documented ;) ):
"For a string, dynamic array, method pointer, or variant result, the
effects are the same
On 06/24/2016 08:19 PM, Michalis Kamburelis wrote:
After upgrading fpc 2.6.4 -> 3.0.0, I'm seeing a bug where (as noted in
subject) reference-counted function results are not being initialized to
nil.
They were never guaranteed to be initialized to nil.
Reference-counted types (unlike other ty
> After upgrading fpc 2.6.4 -> 3.0.0, I'm seeing a bug where (as noted in
> subject) reference-counted function results are not being initialized to
> nil.
They were never guaranteed to be initialized to nil.
Reference-counted types (unlike other types) cannot contain memory
garbage. But it doesn
Hi all,
After upgrading fpc 2.6.4 -> 3.0.0, I'm seeing a bug where (as noted in
subject) reference-counted function results are not being initialized to
nil.
Is this a known bug?
I am seeing it in ansistrings and also dynamic arrays. Here is an
example program to see it with ansistrings:
19 matches
Mail list logo
