Clarify EOF behavior for readMemory

[connor4312]

Currently, VS Code does not deal with unreadable bytes in readMemory requests, so that's just treated as the "end of file"/end of memory range. However that's a very temporary solution.

Currently there's two ways I could see for this to be signalled:

• Via unreadableBytes. In the end of file case, the "number of bytes that must be skipped before a subsequent 'readMemory' request will succeed" is, however, infinite, which cannot be expressed as a numeric JSON type.
• By having the data being shorter than the number of requested bytes (0 the offset is at or after the end of the sequence). If this is something that implementors should depend on, we should document it explicitly.

[haneefdm]

I think yes, better doc. can cut down on questions. About unreadableBytes not even our DA knows the extent of the memory or the memory map. It just means this region is done. We don't know where the next region is, if there is one. Even if we did, practically, they are separated by a Gigabyte or so. So clients should assume that this part of the memory is done for.

So, I am thinking, if the read was partial and the client treating that as EOF, that is fine. There has to be a way to distinguish between that and the fact that the request was made at the wrong time -- when the program was running/busy.

I have seen this a lot. At the time the request was made, the program was paused. But by the time the request has reached the DA, the program is running and more than likely the DA gave an error response. This happens a lot.

Not just for memory reads. Also for evaluate requests which generally precede a memory read. It is a general class of errors where certain requests cannot be satisfied just because the program is running.

Note that there will be debuggers who can satisfy requests even while program is running but even they may not allow requests like stack-traces -- no way to do that without pausing/interrupting execution.

One could say, why doesn't the DA pause, and then satisfy the request? I think requiring that is super invasive and pausing the debugger generates a LOT more incidental traffic.

[connor4312]

unreadableBytes was requested by the original readMemory proposal, and it's in there now, so we must continue to honor it. I think adding a sentence to the documentation on ReadMemoryResponse.data should be sufficient:

The bytes read from memory, encoded using base64. If the decoded length of data is less than the requested count in the original readMemoryRequest, and unreadableBytes is zero or omitted, then the client should assume it's reached the end of readable memory.