Flávio Etrusco schrieb:
Maybe just adding the option to disable the const optimization and
letting the programmer figure out whether it fixes or not a bug is a
good enough addition?
+1 :-)
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.
Martin schrieb:
Fetching content changes, would require to either copy or checksum
*every* const param => that is a different beast (one that I did not
propose...)
Content changes in structured types (TObject!) are not prevented by the
"const" modifier.
While such a restriction is one of t
Martin schrieb:
http://bugs.freepascal.org/view.php?id=19605
It may be easier to discuss here.
* First it needs to be decided, if such a check in itself (ignoring any
obstacles in it's implementation) has a chance to be accepted at all.
IMO a better check would create a (true, unique) copy of
Another option would be to to the entire check, with a special memory
manager.
Let the memory manager, add a byte to each request (probably 4 bytes for
boundaries), and add a ref-counting like structure. This would only be
used by "const param" => const param can use this to mark the block of
On 23/06/2011 22:13, Florian Klämpfl wrote:
Am 23.06.2011 23:03, schrieb Martin:
And what exactly does checkpointer check?
Check if the pointer points into a allocated memory block.
Ok, that would actually work.
even without keep_released it could catch quite some
It should check, that it p
Am 23.06.2011 23:03, schrieb Martin:
> And what exactly does checkpointer check?
Check if the pointer points into a allocated memory block.
Combined with heaptrc.keep_released:=true, this is a very powerful check
and even more if heaptrc is compiled with FPC_HEAPTRC_EXTRA. Downside is
a slight sl
And what exactly does checkpointer check?
That s is not nil ? => s will never be nil. If something goes wrong, s
points to memory of which nothing is known (could be unallocated, could
be allocated by something else)
On 23/06/2011 21:37, Florian Klämpfl wrote:
Am 23.06.2011 22:36, schrieb Ma
On 23/06/2011 21:44, Florian Klämpfl wrote:
Am 23.06.2011 22:31, schrieb Martin:
This is about finding screwups of the refcount. The data modification
detection of strings is a side effect only.
Why is a "screwup" of the ref. count a problem? It is only a problem if
it gets 0 and the string is
Am 23.06.2011 22:31, schrieb Martin:
>
> This is about finding screwups of the refcount. The data modification
> detection of strings is a side effect only.
>
Why is a "screwup" of the ref. count a problem? It is only a problem if
it gets 0 and the string is disposed?
>
>
>
> Anyway, I repea
Am 23.06.2011 22:36, schrieb Martin:
>>
>> procedure Foo(const s: string);
>>begin
>> proc;
> I assume the below is supposed to be the hidden / automatic check?
Yes.
> (since the above was the unwarranted change to s)
>
> But what does it test (besides from being an assignment?
This is
On 23/06/2011 21:22, Florian Klämpfl wrote:
May I propose a more generic solution:
- with some switch (-gc?) a call to checkpointer is inkoved at the end
of a procedure for const ref. counted types. Together with -gh this
catches the common case:
Sorry I do not understand?
{$h+}
var
s : str
On 23/06/2011 21:06, Flávio Etrusco wrote:
On top of what I already wrote on mantis. I believe my initial idea can
be further simplified.
Given: procedure Foo(const s1, s2: string);
What about records, arrays etc. containing ref. counted types?
This case is shlighly different.
(...)
I suppos
May I propose a more generic solution:
- with some switch (-gc?) a call to checkpointer is inkoved at the end
of a procedure for const ref. counted types. Together with -gh this
catches the common case:
{$h+}
var
s : string;
procedure proc;
begin
s:='1234';
end;
procedure Foo(const s:
In our previous episode, Jonas Maebe said:
> > It may bne rare, sure. But it is also one that is very hard to find.
> > Because code like this may run without crash, for a long time, and by the
> > time one notices it, it is hard to track. And *if* const param are used, it
> > is easy to sneak i
>
>>> On top of what I already wrote on mantis. I believe my initial idea can
>>> be further simplified.
>>>
>>> Given: procedure Foo(const s1, s2: string);
>>
>> What about records, arrays etc. containing ref. counted types?
>
> This case is shlighly different.
>(...)
I suppose Florian already k
On 23 Jun 2011, at 21:45, Martin wrote:
> It may bne rare, sure. But it is also one that is very hard to find. Because
> code like this may run without crash, for a long time, and by the time one
> notices it, it is hard to track. And *if* const param are used, it is easy to
> sneak in, even i
On 23/06/2011 20:09, Florian Klämpfl wrote:
Personally I don't see the need for such a check because I consider it
as a seldom corner case but I can understand that people might be
interested in it so if somebody implements it properly, I'am pretty sure
it can be included.
It may bne rare, sure.
Am 23.06.2011 20:59, schrieb Martin:
> http://bugs.freepascal.org/view.php?id=19605
> It may be easier to discuss here.
>
> * First it needs to be decided, if such a check in itself (ignoring any
> obstacles in it's implementation) has a chance to be accepted at all.
> If such a check is not wante
http://bugs.freepascal.org/view.php?id=19605
It may be easier to discuss here.
* First it needs to be decided, if such a check in itself (ignoring any
obstacles in it's implementation) has a chance to be accepted at all.
If such a check is not wanted (even if implementation were trivial),
then
19 matches
Mail list logo
