Should we use unit ctypes for FPC?

[Free-Pascal-meets-SDL-Website]

I wonder,

in sdlstd.inc we define all the types used in SDL2. We lead them back to basic Pascal types. In this example we lead UInt16 back to Word.

PUInt16 = ^UInt16;
UInt16 = Word;

I suggest to have a conditional type conversion bound to the ctypes unit for Free Pascal.

{$IFDEF FPC}
  UInt16 = cuint16;
{$ELSE}
  UInt16 = Word;
{$ENDIF}

The advantage is that type sizes should be chosen even more reliably for different platforms (at least in case of FPC).

[suve]

I was thinking about this myself, recently - and I think it's a good idea, since the whole idea behind the ctypes unit is that it should free us of having to maintain a pascal type <-> C type mapping ourselves. If Delphi doesn't have an analogous unit, then yes, we should hide this behind an {$IFDEF}.

[Free-Pascal-meets-SDL-Website]

the whole idea behind the ctypes unit is that it should free us of having to maintain a pascal type <-> C type mapping ourselves. If Delphi doesn't have an analogous unit, then yes, we should hide this behind an {$IFDEF}.

Exactly!

About Delphi, I'm not sure if there is something similar, but in a quick research I couldn't find anything. To make sure not to break Delphi-compatibility, It can be done as described.

[Free-Pascal-meets-SDL-Website]

I ran into a problem. Ctypes maps C's *char to pcuint8 (pointer C uint8), which is basically correct from a memory point of view (corresponds to PChar or PAnsiChar) but in contrast to PChar/PAnsiChar who allow for some Pascal-magic string allocations, pcuint8 does not. Also, Pascal introduces PChar/PAnsiChar explicitly to handle C's char pointers. If we really want to use ctypes consistently and translate C's char by cchar from ctypes, it means we would need to implement "string functions" ourselves if we want to keep using the SDL2 units conveniently easy.

Otherwise this means, ppl using the units would need to handle strings themselves if function declarations have cchar instead of PAnsiChar as parameter.

Solution 1:
Make an exemption for char and keep using PAnsiChar.

Solution 2:
Use cchar and implement string functons. This is in no way what we can do and have the ressources for.

Solution 3:
Not use Ctypes and carry the whole idea to the grave.

Are there better/other solutions?

[Free-Pascal-meets-SDL-Website]

On further examination I found that it is expected to use PChar instead of pcchar (e. g. here https://github.com/williamhunter/pascal-bindings-for-c). So we retain PAnsiChar in the code and do not change it for the moment. This corresponds to solution 1 above.