C long / unsigned long should be 4-byte int instead of 8-byte long / ulong?

[SuRGeoNix]

Hi, there is an open issue for FFmpeg.AutoGen bindings here which I think should be handled from CppSharp.

The issue is with C long / unsigned long data types that are converted to C# as long / ulong. At least for Windows systems that I've tested the size it should be 4-bytes instead of 8-bytes.

[tritao]

Hey @SuRGeoNix, we get those sizes from Clang using the TargetInfo abstraction:

CppSharp/src/Generator/Extensions/PrimitiveTypeExtensions.cs

Line 31 in 25e2c7c

public static (uint Width, uint Alignment) GetInfo(this PrimitiveType primitive, ParserTargetInfo targetInfo, out bool signed)

We could have a bug but I think its more likely you may be missing a call to setup the correct TargetTriple in ParserOptions, as that's what generally affects those sizes.

To get to the bottom of this, please paste which target triple you are parsing with, and the C line from FFmpeg you are trying to bind, and what CppSharp is outputting. It could be a 32-bit vs. 64-bit setup issue for instance.

[SuRGeoNix]

Hi @tritao and thanks for the quick reply.

The C input is a struct with a field of 'unsigned long field' and the result is a C# struct with a 'ulong field' in windows 64 system.

Just to clarify I'm just using FFmpeg.AutoGen so I can't really tell you much but what I see is that the nuget is multi platform and it does not specify those as I can see here.
However, I tried to specify TargetTriple to "win64" and I still get the same results.

The thing is that FFmpeg.AutoGen in any case is a single NuGet package for all platforms (with the already generated code) so it might need to split to different platforms? (But still the issue remains when specifying TargetTriple)

[SuRGeoNix]

Looking a bit deeper into it, I've noticed that FFmpeg.AutoGen uses the ParserOptions.SetupMSVC(VisualStudioVersion.VS2019) which produces this Triple "x86_64-pc-windows-msvc".

In the debug folder I see the LLVM C14 libs/headers which they have (stdint.h/limits.h). When it parses the source files I see that includes (except the clang debug libs/headers) also the MSVC headers (another stdint.h/limits.h). I'm not sure how it does affect CppSharp afterwards. A funny comment in LLVM limits.h : -

/* Many system headers try to "help us out" by defining these.  No really, we
   know how big each datatype is. */
#undef  SCHAR_MIN
#undef  SCHAR_MAX
#undef  UCHAR_MAX
#undef  SHRT_MIN
#undef  SHRT_MAX
#undef  USHRT_MAX
#undef  INT_MIN
#undef  INT_MAX
#undef  UINT_MAX
#undef  LONG_MIN
#undef  LONG_MAX
#undef  ULONG_MAX

(Possible MSVC vs GCC differences?)

[SuRGeoNix]

Closing this as it can be resolved by CLong / CULong types