[fpc-pascal] FpDebug hands-on: AnsiStrings

[Martin Frb]

On 21/05/2020 20:19, Joost van der Sluis wrote:
> Might be, you could see this as a saveguard. But my goal is to cut-out 
> the middle part of the string. That's formatting....
Well, we should have the safeguard. And make it configurable.
... See below

>> Part 2 is formatting related....  In most cases the user does not 
>> need a 10kb string, the user may want offset 1500 len 500. Ideally 
>> then the debugger only reads that part. That part may move to the 
>> formatter. But also may need an extension to target reading the 
>> correct subset of the data.
> Indeed

Now for your goal. That does not conflict with the safeguard. When 
"getting the middle of a string" is added, then the safeguard still 
applies. (Well maybe).

If the user says get me SomeString[1000..1999] (1000 chars) => 
technically the safeguard should apply (no problem if user configurable.
This may sound nonesense, when the user gives hardcode dimensions. But 
what if
    SomeString[1000..1000+i]

Btw, It may be a good idea to teach pascal parser that syntax. (also for 
arrays)

Anyway: A formatter can temp increase the safeguard. So there is no 
problem with keeping it on this level.

To get substrings, one needs to be able to read the length, without 
actually starting to retrieve the text. (would be a waste, to retrieve 
text that will not be needed).
So maybe implement
   GetMemberCount
to return the amount of "char"s (bytes / words for widestring)

And then one new method is needed to get the substring.
Need to check which other dwarf types could benefit. (For arrays members 
are retrieved individually, but maybe target mem could be read and 
cached (like for structures)


>
>> If needed I would rather add the 2 new functions. Though it seems the 
>> data is actually returned as part of the longstring?
>
> No, it is not, because the result is assigned to an AnsiString, and 
> therefor the compiler could decide to change it's codepage. In this 
> function or somewhere further down the line.
Then the result type should be changed to rawbytestring or whatever is safe?
At least so that the formatter can get it correct. Other calling code 
may assign it to whatever that code wants....

>
> What you are saying is that the TFpValue doesn't do the formatting. 
> But it retrieves the data. And indeed it's very suitable for that.
Should be that way.

>
> But then, we should be consistent. And do not let any other classes 
> (The formatter I was talking about, but also the PrettyPrinter and 
> such) retrieve data. Such a class could always create a TFpValue for 
> their own use....
Have to look at it case by case. Ideally yes.

It may have to be judged for performance:
Array members are gotten by re-using the same TFpValue. Otherwise 
retrieving a large array would be expensive...
If the formatter would all the sudden need to create extra object for 
each array value....

Anyway case by case.