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