On 2026-05-27 13:45, Martin Frb via fpc-devel wrote:
On 27/05/2026 13:03, Tomas Hajny via fpc-devel wrote:
I can't imagine a reasonable scenario when a user might want to
perform a modification of a refcounted variable of the program being
debugged by using "copy on write".
If the user assigns a new (char) value to
MyAnsiString[3]
then they might expect that.
After all, this is what would have happened, had there been code
doing
MyAnsiString[3] := '?';
Yes, but there is an important difference there. If there's code
modifying the value, this code uses this copy from that point on.
However, if a user wants to modify some data in a debugger, this user
probably wants to do it in order of his code started to use the new
value instead of the original value, not because of being interested
in having another copy of the original data with a different value
(which wouldn't be used by the debugged code any longer).
I am not sure if I follow...
procedure DoFoo(s: AnsiString);
begin
...
// paused here
...
if s = ... then
...
end;
if the user tells the debugger to modify
s[1] to be '?'
I.e. in the Lazarus IDE would open the "Evaluate/Modify" window, enter:
s[1]
and set the new value to '?'.
Then that user most likely does not want the variable in the caller to
be changed?
Actually, I'd expect that _if_ the user wants to modify the value within
the debugger, he wants to have full picture of effects of the modified
value rather than just parcial effect which would never match real case
scenario when the variable has a different value. Moreover, creating a
copy for the modified version wouldn't change the reference used in the
code of DoFoo, would it? Otherwise you'd need to modify not only the
value, but also all parts of code in DoFoo retrieving this value to
point to the new copy instead, right?
.
.
Function calls in watches are very tricky in any case and allowing
them in case of reference counted parameters sounds like a recipe for
problems as far as I can tell (I can imagine quite a few cases when
this may lead to complete change of the behaviour of the program being
debugged). If nothing else, the debugger should warn the users trying
to do that.
I don't use them myself. I got burned back in the days of Delphi 5
(iirc). When I couldn't get the bug to trigger under the debugger,
because I was watching
SomeControl.Handle
(the property with getter)
And hence the debugger did create the handle, and the error was gone in
the debugger.
But...
- there is a huge amount of people who deeply believe they can't live
without function calls (including property getters)
- who have not yet been burned, or if they have they are not aware of
it
- who will not believe that it will ever happen to them.
So well, let them have it. They have been warned...
OK, understood, we clearly see it the same way.
----------------
Currently, in the few cases where FpDebug can detect an AnsiString as
such (Dwarf-3), it can handle it in function calls (definitely as
result, iirc as param too, including from constant in the user
expression).
And FpDebug does do the correct additional calls to the rec cnt
functions. (via the linker symbols, that usually are available)
Adding the tag will ensure FpDebug can more accurately/safely detect
such strings.
OK, that indeed makes sense.
Tomas
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
