Don't expose a memory reference for non-pointer evaluation results

[tieo]

Problem

In a debug data-tip (or the Variables view), hovering a non-pointer scalar shows the value correctly but attaches a memoryReference, so VS Code renders the "view binary data" hex icon and clicking it navigates to an address equal to the value. For example, hovering a uint32_t stsdig whose value is 1 offers a memory view that opens at address 0x1.

Cause

AD7Property.GetMemoryContext (src/MIDebugEngine/AD7.Impl/AD7Property.cs) tries to interpret the result's display value as a memory address, for every type:

// try to interpret the result as an address
string v = _variableInformation.Value;
...
UInt64.TryParse(v, NumberStyles.Any, ...)   // "1" -> addr = 1
ppMemory = new AD7MemoryAddress(_engine, addr, null);

For a pointer this is correct — the value is an address (0x...). For a plain scalar (e.g. int/uint32_t) the value is a number, not an address, so UInt64.TryParse("1") succeeds and the memory reference becomes 0x1. OpenDebugAD7 then reports that as memoryReference on the evaluate/variables response, and VS Code's memory navigation goes to address 1.

Fix

Only treat the value as an address when the result is a pointer (or an array, which already re-evaluates to its address with &(...) further down). For any other type, return S_GETMEMORYCONTEXT_NO_MEMORY_CONTEXT so no memoryReference is reported and no spurious memory icon/navigation appears.

bool isArrayValue = v[0] == '[' && v[v.Length - 1] == ']';
string typeName = _variableInformation.TypeName;
bool isPointer = !string.IsNullOrEmpty(typeName) && typeName.TrimEnd().EndsWith("*", StringComparison.Ordinal);
if (!isArrayValue && !isPointer)
{
    return AD7_HRESULT.S_GETMEMORYCONTEXT_NO_MEMORY_CONTEXT;
}

TypeName is already on IVariableInformation, and the same EndsWith("*") pointer test is used elsewhere in Variables.cs (IsPointer).

Testing

Built the patched engine and ran it against a live cppdbg/gdb session:

• Pointer (int32_t *, const uint32_t *) — still shows its address and the memory icon, unchanged.
• Scalar (uint32_t) — now shows just the value, with no memory icon and no navigation to 0x<value>.
• Array — unchanged (still resolves to its base address via the existing &(...) path).

Note: the change was written with the help of an LLM and verified manually in VS Code against a real gdb target.

[gregg-miskelly]

Hi @tieo thank you for taking the time to investigate this.

I didn't debug this, so apologies if I am incorrect, but, at least in Visual Studio, I believe your change would break entering an address into the memory or disassembly window. I haven't looked at how the memory or disassembly windows work in VS Code to know if they let the user enter an expression for the memory address to know if they have the same problem or not.

Are you looking specifically to block the memory window just from data tips?

[tieo]

Sadly I don't have Visual Studio (just Code), but to quickly explain why I made this:

What it currently looks like:

(see the int value being treated like an address, same as the pointer)

What it should look like (and does if I use the engine patch above):

I'm sadly pretty clueless about the inner workings of the engine or how it affects VS, which is why I used an LLM to make the edit. It also proposed to move the edit to OpenDebugAD7.dll (see new commit, tested again only in VSC).
I could also convert to an issue if that's better than "Vibe Coding" my way through this 🤠.