Community input for a new C binding generator project

Jacob Carlborg doob at me.com
Wed Apr 2 08:49:18 PDT 2014


On 2014-04-02 16:33, James Buren wrote:
> I have thought of designing a new C binding generator that tries to do
> more than dstep currently does.

What's the advantage of starting from scratch by building a new tool 
instead of contributing to DStep?

> At the very least that would include
> automatic conversion of simple macros. Such as: characters, strings,
> aliases, integers, constant integer expressions, etc. Another thing I
> wish to add is mapping of standard C types to their D types in
> core.stdc.* if it is already defined there.
>
> However, while doing research for the project, I have come across a
> number of concerns I have. So, I am asking for community input before I
> get serious with this project because I want to actually make something
> people would want to use.
>
> Specifically, this is what I need to know about:
>
> 1) C has many standards (C89/C99/C11) and non-standard extensions (GNU
> C). By the very nature of C grammar, it can be quite difficult to parse
> properly. Would anyone care if I excluded non-standard features that may
> be present in a header? For example, non-standard bitfields -- they use
> integers other than 'int'. This is non-portable behavior.

Use a compiler that can already parse C, i.e. Clang.

> 2) As an extension to above, should I bother supporting rarely used
> features? Some of them are non-standard but others are standard. For
> example, #pragma pack() or GNU attributes and how those effect struct
> alignment in the D interface module is non-standard. Another example is
> converting inline functions, which is supported via C99 standard.

Use a compiler that can handle those extensions, i.e. Clang.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list