From ccoutant@gmail.com Tue May 5 00:34:26 2026 From: ccoutant@gmail.com (Cary Coutant) Date: Mon, 4 May 2026 17:34:26 -0700 Subject: [Dwarf-discuss] Discussion: ref counted types / string, arrays in Pascal In-Reply-To: References: Message-ID: 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: