OSGeo
CSharp bindings: Add VSIGetMemFileBuffer bindings
Fixes #11032
This is the first time I have dealt with configuration SWIG, and I'm not a C++ expert, so there might be a better way of generating the bindings. I tried to take inspiration of how the other SWIG interface code was written.
It is intentional that the vsi_l_offset is mapped to "int" in C#, since the use case will in most cases probably be:
IntPtr ptr = Gdal.GetMemFileBuffer(vsiPath, out int length, false);
byte[] buffer = new byte[length];
Marshal.Copy(ptr, buffer, 0, length);
And Marshal.Copy only supports int for buffer length. It seems like unsigned long and unsigned long long pointers are handled similarly in other parts of the binding code (casted to signed int), so hopefully this is OK.
It is intentional that the
vsi_l_offsetis mapped to "int" in C#
probably not... ? Seeing https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/integral-numeric-types, it looks like it should be "long" for a 64 bit integer, actually "ulong" since it is a unsigned one
It is intentional that the
vsi_l_offsetis mapped to "int" in C#probably not... ? Seeing https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/integral-numeric-types, it looks like it should be "long" for a 64 bit integer, actually "ulong" since it is a unsigned one
Yes. I just meant that it was intentional that it was cast to int on the C# side since the Marshal.Copy does not have ulong overload for buffer length, so it was to keep it "user friendly" on the C# side. I noticed that in cpl.i vsi_l_offset is changed to GIntBig, so I thought it might have been OK to cast to signed int. But I guess to keep it as close as possible to the C/C++ API that it should be ulong!
coverage: 69.445% (-0.002%) from 69.447% when pulling 34afc2d2c4d123964bfdae0d02b31317858034be on EmilRybergAkson:feature/getmemfilebuffer-csharp into 5033ea25568aa9e0c7901eeae8b4a5f529bf3325 on OSGeo:master.
