[Dwarf-discuss] Discussion: ref counted types / string, arrays in Pascal

[Cary Coutant]

Thanks for the extra info. This still feels a little incomplete in terms of
a formal DWARF proposal, though. What specific additions would you make to
DWARF to support your desired feature set?

-cary


On Fri, Apr 24, 2026 at 3:43 AM Martin via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> Following up my other mail on strings...
>
> Here are some details on ref-counts in Pascal.
>
> Note, the compiler devs currently are adding "smart pointers" which to
> my understanding will introduce similar refcounts for other types. But I
> do not yet have details on that.
>
> The entire discussion is about "hidden" refcounts. That is refcounts not
> added by the user in the declaration of a type, but internally being
> part of the type.
> I.e. "COM" interfaces do NOT fall into this, as their refcount is
> defined as normal field in the underlying object.
>
> Currently in pascal there are
>
> Some string types like AnsiStrings.
> - the implement copy-on-write if the refcount is greater than 1 (and
> they are written to)
>
> Dynamic arrays (var-length)
> - the do not implement copy-on-write
>
> ref-counts are managed if the data is assigned to other vars, or passed
> as parameter.
>
> There are methods (uniquestring, SetLength) that return a copy with
> refcount = 1.
>
>
>
> In debugging, this information may be important for a user.
>
> - When values in an array are changed. (either by code that is stepped,
> or by modifying data via the debugger). => The user may need to know if
> that has side effects on other copies of an array
>
> - Debugging code that accesses a string via "PChar" (pointer to char).
> This bypasses copy-on-write, this easily leads to bugs, that can only be
> found checking the refcount
>
> - If a debugger allows to modify data in a string, then the debugger
> itself needs to know if that string needs to be copied
>
>
> For the debugger itself the information is important when
>
> - modifying data
> - creating instances of the data (e.g. when the user calls a function as
> part of inspecting values, and a string needs to be injected as argument)
>     p lowercase('AbcDef')
>
>
> Requirements
>
> DWARF would need to be able to add "refcount" info to different types.
> To start with this is DW_TAG_string_type and DW_TAG_array_type.
> Other types may later be needed too.
>
> The info needs to describe
> - the (relative) location of the refcount
> - the size of the number
>
> If a debugger also should be able to modify/create/free the data, then
> more is needed. I would at first say a list of functions for various
> tasks. But in other languages they may not exist, and instead common
> actions could be described by other means.
> So the actions would need a choice of what the describe (maybe by use of
> different forms, maybe nested tags, with attributes?)
> Actions might be
> - creation (alloc mem)
> - init (after alloc mem)
> - inc/dec ref => those default to just modifying the field
> - get copy that may be modified?
>
>
>
> Additional considerations
>
> I talked about strings being passed as parameters to function (that are
> called by the debugger).
>
> In Pascal some function can be optimised so their string argument does
> not get the increment.
> This could be covered by either
> - a copy of the type, with a "no action" for the inc/dec
> - a flag on the variable (allowing the type to be the same, which may be
> desirable)
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20260504/da98cbde/attachment.htm>