Community input for a new C binding generator project

James Buren ryu0 at ymail.com
Wed Apr 2 07:33:03 PDT 2014


I have thought of designing a new C binding generator that tries 
to do more than dstep currently does. 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.

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.

3) Should I provide an interface for mapping preprocessor macros 
which cannot be automatically converted by machine logic? For 
example, function macros cannot be converted automatically 
because you can't be sure what type of argument is expected. 
Other macros may not be worth converting because they are simply 
used for generating code.

4) As an extension to questions 1 and 2, is it worth it to you 
for non-standard C features to be supported? This would likely 
make generating a portable D interface more difficult as the D 
interface is limited by what the platform's C compiler supports. 
For example, if struct alignment is used but the platform's C 
compiler does not support this non-standard feature, then the D 
interface would have to exclude it from this platform's version 
of the module.

5) Should I avoid reusing code from a GPLv2 / GPLv3 project? I'm 
not sure if this makes anyone uncomfortable. Supposedly most GPL 
program output retains the license of the input, but I'm not 
totally convinced. I am not sure if the viral nature of the GPL 
would make people unwilling to use my tool.

6) Anything else you would like to see in a C binding generator? 
I may not implement it, but knowing what people want would help 
me anyway.

Thank you for reading this.


More information about the Digitalmars-d mailing list