<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In Pascal the index normally is 1 based.<br>But compilers like FPC and Delphi support a directive "{$ZEROBASEDSTRINGS}"<br><a href="https://gitlab.com/freepascal.org/fpc/documentation/-/work_items/39484" rel="noreferrer" target="_blank">https://gitlab.com/freepascal.org/fpc/documentation/-/work_items/39484<br></a>which changes this to 0 based.</blockquote><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It might be desire-able to add this to DWARF.</blockquote></div><div><br></div><div>You mean DW_TAG_string_type, right?</div><div><br></div><div>This seems like a reasonable extension. We've always claimed DWARF is "descriptive, not prescriptive", meaning that if a tag or attribute makes sense in a context we don't cover in the document, it's still generally OK. In this case, the presence of a DW_AT_lower_bound attribute in a DW_TAG_string_type would have an obvious meaning, and a consumer that ignores it is no worse off than if the producer omitted it.</div><div><br></div><div>It may not be quite as obvious as it sounds, though: DW_AT_lower_bound is currently defined only for subrange types (DW_TAG_generic_subrange and DW_TAG_subrange_type), which are used to define the bounds of each dimension of an array. Since strings are inherently one-dimensional, the use of one or more subrange tags as children of DW_TAG_string_type seems unnecessary (unless anyone is thinking of proposing multi-dimensional strings!).</div><div><br></div><div>Given a known use case for DW_AT_lower_bound as an attribute of DW_TAG_string_type, I'd support a proposal to add it to DWARF V6. My opinion is that you should feel free to use it anyway in current versions of DWARF, as long as you have an agreement with any relevant debuggers.</div><div><br></div><div>What about DW_AT_upper_bound? For string types, we have DW_AT_string_length, et al., but providing lower and upper bounds would be an alternate way to represent the string length. The argument for this is not as strong: if you replace DW_AT_string_length with DW_AT_upper_bound, you risk breaking some consumers.</div><div><br></div><div>If you like, I'll file this as a new proposal (without upper bound).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also Pascal strings (some of them) are ref-counted and have other fields<br>(like encoding).</blockquote><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ref-count may be something generic (also applies to some arrays). And<br>may therefore deserve an attribute of its own?</blockquote></div><div><br></div><div>With respect to ref counts, I'd like to see a more fleshed-out proposal with some background about how it could be useful to a consumer.</div><div><br></div><div>-cary</div><div><br></div></div>