JsonSerializer and IntPtr

[Dimension4]

This snippet (using .net 5)

JsonSerializer.Serialize(new {Handle = (IntPtr) 123});

returns {"Handle":{}}.

Given that IntPtr implements ISerializable I'd expect that IntPtr is serialized as a number in json. Why can't I serialize the IntPtr? And why do I get an empty object instead of an exception that the type isn't supported?

[Clockwork-Muse]

I'd expect that IntPtr is serialized as a number in json.

... and what would you expect to happen on deserialization? The value hopefully won't be valid (if it is, you could have far worse problems).

[Dimension4]

and what would you expect to happen on deserialization?

I would expect to get the same IntPtr back that I serialized. Just because one could misuse that value/mechanism doesn't mean it shouldn't be possible. I have a valid use case, which is passing window handles between process boundaries (please don't ask why). Another use case could be managing of shared memory between processes. Admittedly, it is a niche one and I know quite a few ways to work around this issue.

The problem I'm having with the current state is that it's just silently ignored. If it's not supported it should at least tell me so. Throwing a NotSupportedException for example. Imo, it should be possible. IntPtr implements ISerializable so there are serialization mechanisms that do support it. I don't see a reason why it should be different for json.

[tannergooding]

if it is, you could have far worse problems)

Notably, this is fine for 32->64 and 64->64 bit systems. Likewise, it is valid for 64->32 scenarios when value is 32-bits or less.
Not every usage of IntPtr and/or UIntPtr is for an opaque handle. In many cases, it is simply a native sized integer (nint or nuint) and is 100% valid to serialize, deserialize, and even use once deserialized.

[GrabYourPitchforks]

FWIW the [Serializable] attribute and ISerializable interface are a separate concept used for legacy serializers like NetDataContractSerializer and BinaryFormatter. They're not really relevant for System.Text.Json and other modern serialization frameworks. I wouldn't draw too close an association between a type being attributed as such and that same type being handled properly by a modern serialization framework.

I agree with @tannergooding's analysis above. If you imagine that IntPtr and UIntPtr are really just the backing types for nint and nuint, they should be serialized as straight integers. One potential wrench: what happens when you deserialize a 64-bit value into a 32-bit process? I'd assume it'd result in the same error as trying to deserialize the value 11222333444 into a property typed as Int32.

(Also, please don't serialize actual handle values. They're almost certainly not going to be valid on the other side.)

[Dimension4]

(Also, please don't serialize actual handle values. They're almost certainly not going to be valid on the other side.)

In my defense, I used it in this specific scenario to exchange window handles between processes on the same machine 😄. I know it's dangerous but I have to deal with cross process window ownership...