Known Limitations

Due to limited expressiveness of the Cangjie language, cjbind currently has the following limitations:

Bitfield

Cangjie does not provide native bitfield support, so cjbind cannot directly generate bindings for bitfields. When encountering bitfields, cjbind treats them as opaque types.

There are plans to simulate bitfields using VArray, but this has not been implemented yet.

Union

Cangjie does not provide native union support, so cjbind cannot directly generate bindings for unions. When encountering unions, cjbind treats them as opaque types.

There are plans to simulate unions using VArray, but this has not been implemented yet.

Macros

Cangjie currently lacks a suitable expression parsing library, making it impossible to directly evaluate macro values. When encountering macros, cjbind constructs a C file and then calls clang to evaluate the expression value.

There are plans to add support for simple string and numeric macros, but this has not been implemented yet.

Opaque Types

cjbind attempts to generate bindings for opaque types while attaching a constructor that always throws exceptions, but users may still create struct instances using zeroValue. The memory layout of opaque types is not always guaranteed to be correct, so extra caution is needed when using opaque types. Typically, memory allocation should not be performed on the Cangjie side; instead, pointers returned from the C side should be held.

Memory Alignment

Cangjie does not provide syntax for alignment control, so cjbind uses C's default alignment. If the C code uses methods like #pragma pack or __attribute__((packed)) to control alignment, the binding code generated by cjbind may have issues. You can track the progress of this issue at Issue#1618.

Flexible Array Members

Cangjie does not support flexible array members, so cjbind skips structs containing flexible array members.

Calling Convention

cjbind attempts to infer the calling convention based on function signatures in the C code, but errors may occur. If you find that the function signature in the binding code is incorrect, you should manually modify the binding code.

Due to unclear documentation in Cangjie regarding the STDCALL calling convention, the currently generated calling convention is always CDECL. You can track the progress of this issue at Issue#1595.