Code generation should also create byte[] parameter overloads where byte* is observed about pinvoke HOT 7 CLOSED

Well, in this case why not having only byte[]?
Is there any reason to actually need the IntPtr and byte* overloads?

I thought we introduced pointers to have more meaningful parameters, and code generation to solve the gap for those languages that cannot call pointer exposing methods, but on those scenarios where we can use an array I don't see the need of the pointer at all (since the parameter is meaningful enough and it can be used by all languages)

from pinvoke.

@jmelosegui: that's a fair question.
There are two reasons for using byte* instead of byte[]. These reasons aren't usually compelling enough to warrant using byte* so most methods that can should probably use byte[]. But for a few methods or libraries, they are quite compelling. They are:

1. byte* can point anywhere, including (for example) the middle of a byte[]. So if you already have an array with the content you want to pass in, but that content isn't at the start of the array, byte* lets you point directly at it, whereas byte[] requires that you copy the whole content into a new array just so it's at the beginning of it.
2. byte* enables you to be certain that the memory doesn't get copied or moved around by the CLR. byte[] as a reference type can be moved during a GC's defragmentation of memory. If your data is sensitive (say, as part of a cryptographic operation) best practices suggest you scrub the buffer when you're done so that memory dumps don't capture the data. But if the buffer gets copied around in memory by the GC, you can't effectively scrub all the old locations. Locking the buffer location mitigates this, and a very convenient way to do this (if it's all local variables within a method) is using C# fixed with pointers and not messing with multiple levels of try/finally and GC pinning a byte[].

So I expect to use this enhancement primarily in the BCrypt and NCrypt libraries (where I'm already writing these overloads by hand) and probably nowhere else.

from pinvoke.

I'm also using pointer inside arrays (Wrapped in an ArraySegment) for IO access to USB devices without allocating memory for each call.

It's not necessary for most API but if the codegen can do them automatically, why not have them ?

from pinvoke.

Thank you @AArnott and @vbfox for pointing out those use cases. Now I get the reasons behind this issue.

from pinvoke.

I've edited the proposal to include the addition of the MarshalAsAttribute in the generated code.

from pinvoke.

I've removed [MarshalAs], since the generated methods are never P/Invoke methods themselves so it's not applicable.
Also: I've added a 3rd overload for folks who want to pass in byte[] and native pointers for other parameters. I discovered the need for this combination during the migration to the code generated second overload -- a lot of my own extra overloads had this combination.

from pinvoke.

Also: I've added a 3rd overload for folks who want to pass in byte[] and native pointers for other parameters.

That makes a lot sense.

from pinvoke.