Should we use unit ctypes for FPC? #26
Comments
|
I was thinking about this myself, recently - and I think it's a good idea, since the whole idea behind the |
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. |
|
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: Solution 2: Solution 3: Are there better/other solutions? |
|
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. |
Use ctypes unit for c-type definitions if FPC is used for compilation Compare issue #26 for discussion and details about this PR. Main features: - map all variables/parameters/return values consistently against native C types by using ctypes unit (FPC) or our new ctypes.inc (Delphi + others) - use one naming style (style from ctypes unit) throughout the whole project (cint instead of a mixture of Integer/Int/SInt32/UInt32/...) - prevent access violations or unpredictable behaviour by using/expecting accidently wrong memory size of data types (see e.g. C's int on different platforms) - makes the code much more comprehensible and tracking of memory related bugs much easier Necessity: As a Pascal developer you need to know the exact C variable type of every parameter of the parameter list of a function, instead of what we believe the C function is asking for. E.g. prior to this update C's int was often translated to SInt32, which will work well most often, but as a Pascal developer it is hidden to you, that the platform dependent int is actually expected. This may raise bugs when developing for a system where int does not correspond to SInt32.
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.
I suggest to have a conditional type conversion bound to the ctypes unit for Free Pascal.
The advantage is that type sizes should be chosen even more reliably for different platforms (at least in case of FPC).
The text was updated successfully, but these errors were encountered: