Proposal: IntPtr and UIntPtr Literals

[vcsjones]

I propose that literal suffixes for IntPtr and UIntPtr be added. For example:

var example1 = 2n;
var example2 = 2un;
var example3 = -1n;

Where the literal is equivalent to new IntPtr(2), new UIntPtr(2), and new IntPtr(-1) respectively.

The primary need for this is platform invoke or any situation where native integers are used. Many Win32 APIs take magic handle values, or null (0n). This would also bring parity to F# which already supports this feature.

(copied from dotnet/roslyn#4273)

[tannergooding]

I think the primary issue here is that anything over int.MaxValue would throw an OverflowException at runtime.

Additionally, I'm trying to think of where literal IntPtr would be required, and it tends to be limited to well defined constant values (such as 0 and -1). For the first scenario, IntPtr.Zero is available. For others, you can create your own static readonly or just do (IntPtr)(-1).

I do think, given that IntPtr is a CLR primitive type, having literal values makes sense. I'm just not sure of the overall use case here (even my own proposal on exposing the operators #48, is known to be a very niche use-case).

[jnm2]

I think the primary issue here is that anything over int.MaxValue would throw an OverflowException at runtime.

I'm confused; even when running 64-bit? And wouldn't the compiler be able to error if you're targeting x86, and warn if you're targeting AnyCPU?

[tannergooding]

Yes, only throws on 32-bit...

However, even for interop code, you can generally write it in a way to make it portable (this is why you are using IntPtr in the first place, if you didn't care about platform portability, it is more efficient to just use int or long anyways since operators, constants, and various optimizations are available).

I'm also honestly interested in a case where you need a large number IntPtr literals. Most of the interop code I've seen/written involves getting an IntPtr back from native code. When that IntPtr is a handle, the value is either valid (could potentially be any value) or invalid (represented by 0 or -1, generally). When it is used to represent something like size_t, I generally don't have a hardcoded value, and if I do, they are infrequent enough that doing (IntPtr)(value) for the initialization is sufficient.

What I have found to be frequently in need of is the ability to perform basic arithmetic on IntPtr values, for when they represent something like a size_t.

[vcsjones]

I'm also honestly interested in a case where you need a large number IntPtr literals. Most of the interop code I've seen/written involves getting an IntPtr back from native code. When that IntPtr is a handle, the value is either valid

I tried to capture that example in the issue from the Roslyn repo. My example was CertVerifyCertificateChainPolicy, which has a parameter named pszPolicyOID that is a native sized integer. To copy the relevant information:

As a final example, the Win32 function CertVerifyCertificateChainPolicy's parameter pszPolicyOID is declared as a LPCSTR but is really just native integers cast to that type. So if we wanted to use CERT_CHAIN_POLICY_SSL as value for the first parameter, I would use (IntPtr)4.

My real use case is interoping with non-Microsoft libraries that use size_t (and similar) for everything, inexplicably.

[vcsjones]

I also can't resist saying "F# has it".

[tannergooding]

I understand the need for improvement in relation to interop and support for native sized integers in C#. I'm just trying to understand how this case would specifically improve it.

Even in the example you gave, the best you're going to get is:

public static readonly IntPtr CERT_CHAIN_POLICY_BASE = 1n;
public static readonly IntPtr CERT_CHAIN_POLICY_AUTHENTICODE = 2n;
public static readonly IntPtr CERT_CHAIN_POLICY_AUTHENTICODE_TS = 3n;
public static readonly IntPtr CERT_CHAIN_POLICY_SSL = 4n;
public static readonly IntPtr CERT_CHAIN_POLICY_BASIC_CONSTRAINTS = 5n;
public static readonly IntPtr CERT_CHAIN_POLICY_NT_AUTH = 6n;
public static readonly IntPtr CERT_CHAIN_POLICY_MICROSOFT_ROOT = 7n;
public static readonly IntPtr CERT_CHAIN_POLICY_EV = 8n;
public static readonly IntPtr CERT_CHAIN_POLICY_SSL_F12 = 9n;

[DllImport("Crypt32.dll")]
public static extern int CertVerifyCertificateChainPolicy(
    [In] IntPtr pszPolicyOID,
    [In] ref CERT_CHAIN_CONTEXT pChainContext,
    [In] ref CERT_CHAIN_POLICY_PARA pPolicyPara,
    [In, Out] ref CERT_CHAIN_POLICY_STATUS pPolicyStatus
);

However, this is easily "improved" by doing the following instead (uses constants, the cast is optimized away, and abstracts the nitty gritty details from the consumer, even if that consumer is you).

public enum CERT_CHAIN_POLICY : int
{
    BASE = 1,
    AUTHENTICODE = 2,
    AUTHENTICODE_TS = 3,
    SSL = 4,
    BASIC_CONSTRAINTS = 5,
    NT_AUTH = 6,
    MICROSOFT_ROOT = 7,
    EV = 8,
    SSL_F12 = 9
}

[DllImport("Crypt32.dll")]
public static extern int CertVerifyCertificateChainPolicy(
    [In] IntPtr pszPolicyOID,
    [In] ref CERT_CHAIN_CONTEXT pChainContext,
    [In] ref CERT_CHAIN_POLICY_PARA pPolicyPara,
    [In, Out] ref CERT_CHAIN_POLICY_STATUS pPolicyStatus
);

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static bool CertVerifyCertificateChainPolicy(
    [In] CERT_CHAIN_POLICY pszPolicyOID,
    [In] ref CERT_CHAIN_CONTEXT pChainContext,
    [In] ref CERT_CHAIN_POLICY_PARA pPolicyPara,
    [In, Out] ref CERT_CHAIN_POLICY_STATUS pPolicyStatus)
{
    var result = CertVerifyCertificateChainPolicy(
        (IntPtr)(pszPolicyOID),
        ref pChainContext,
        ref pPolicyPara,
        ref pPolicyStatus
    );
    return (result != 0);
}

Now, if we had constant IntPtr as well, I think this would be a different story entirely 😄

[fanoI]

Well at this point one could relaunch with this:

public enum CERT_CHAIN_POLICY : IntPtr
{
    BASE = 1,
    AUTHENTICODE = 2,
    AUTHENTICODE_TS = 3,
    SSL = 4,
    BASIC_CONSTRAINTS = 5,
    NT_AUTH = 6,
    MICROSOFT_ROOT = 7,
    EV = 8,
    SSL_F12 = 9
}

So no cast is needed in any case 😄

[jnm2]

That would make my interop life nicer, but I know it's going to be hard to justify the language feature when interop is so rare.

[tannergooding]

@fanoI, how would that be possible. Just because you have language literal support, doesn't mean you have runtime literal support. I can declare decimal d = 0m, but I can't do public enum SomeEnum : decimal.

Likewise, I can do const string s = "blah" (which does have runtime literal support) but I can't do public enum SomeEnum : string.

If we had constant IntPtr (that is actual runtime literals) and enum was extended to support any runtime literal type, then I would think this would be reasonable 😄.

Without the above, this becomes syntactic sugar with bad perf.

[vcsjones]

If we had constant IntPtr (that is actual runtime literals)

Isn't that what nativeint is in the runtime world? To my knowledge, IntPtr constants are possible outside of C#.

[tannergooding]

native int is a primitive data type in the runtime. However, there is no native int constant. Just bool, bytearray, char, float32, float64, int8, int16, int32, int64, unsigned int8, unsigned int32, unsigned int64, qstring, or nullref. II.16.2 in ECMA-335 covers the valid field init metadata allowed.

[tannergooding]

Looks like I was partially wrong on one thing though. The runtime does apparently have support for IntPtr enums:

The
symbols of an enum are represented by an underlying integer type: one of { bool, char, int8,
unsigned int8, int16, unsigned int16, int32, unsigned int32, int64, unsigned int64, native int,
unsigned native int }

However, I'm wondering how you would be expected to declare a native int literal...

[tannergooding]

Ah, here it is:

The load constant (ldc.*) instructions are used to load constants of type int32,
int64, float32, or float64. Native size constants (type native int) shall be created by
conversion from int32 (conversion from int64 would not be portable) using conv.i or conv.u.

So, it looks like this would work and the runtime has all the necessary 'stuff' already. The limitation is that all literal values would need to be size int32.

[jnm2]

The limitation is that all literal values would need to be size int32.

Which makes -1 and -2 very interesting depending on sign extension.

[tannergooding]

@jnm2, the way those are extended are actually well defined:

However, there is a bug here when overflow/underflow is enabled: https://github.com/dotnet/coreclr/issues/9591

[tannergooding]

@vcsjones, it would be helpful if you could update the proposal to indicate that the runtime does currently support native int (System.IntPtr) literals, and possibly extend the proposal to indicate that enum should support extending off native int (System.IntPtr) as well.

[temporaryfile]

IntPtr/UIntPtr should be represented as intptr/uintptr keywords and they should support all the same bitwise/arithmetic operations as the other integral types. Otherwise I simply continue using my custom "[U]IntPtrEx" struct with operator overloads and skip the topic. I can't imagine anyone being excited that C# is being limited by VB for academic reasons.