[SAoC] 'DPP with Linux kernel headers' Project Thread
cristian.becerescu at yahoo.com
Mon Nov 25 14:59:17 UTC 2019
Update for week 1 of Milestone 3
(1) I've identified the actual cause for a previous issue and
also implemented a solution for it:
> ---(Maybe) Bug #6---
> Error: undefined identifier xattr_handler
> The above happens in a struct declaration (a field of that type
> is declared) and also in a function declaration (a parameter of
> that type). The struct declaration for xattr_handler is not in
> the generated D file. Will look more into this.
The problem there was that we would have something like this:
void f(struct A**); // C code; A is undeclared
and, because A is undeclared, DPP should generate an plain
'struct A;'. It turns out that previously, DPP was only looking
at the cursor type for the first pointee of 'struct A**', which
was 'struct A*' (which is not a Record type). So DPP would not
generate the corresponding plain struct.
The solution is simply moving on the pointee type until the
cursor type is not a Pointer type (so eventually we would get to
the Record type in the case above).
(2) Found another bug, this time about bitfields. A succinct
explanation and a small example can be found here:
(3) I've tried using DPP with other kernel headers as well
(specifically netdevice.h), and usually I get an error telling me
the resources have been exhausted.
My guess is that the issue is the 'lines' array, which contains
all of the lines to be written in the generated D file. As far as
I know, we don't flush at any point during this process. I assume
this array gets very large at some point (I've seen a maximum of
~100K generated D files so far, although other factors could be
also impactful, maybe the AST).
I thought of two approaches here: either try to write to the file
when 'lines' gets too big, or translate each C header into
different D modules. I'm still open to suggestions.
(4) I still have not got to the cause of this (I assume it's a
sort of redirection of stderr, but I can't reproduce it with any
warnings I tried):
> ---Bug #3---
> In some cases, dpp writes a clang warning into the generated D
> file. For example > (for virtio.h):
>foo.d.tmp:81822:141: warning: __VA_ARGS__ can only appear in the
>expansion of a C99 variadic macro #define __PVOP_VCALL ( op ,
>pre , post, ... ) ____PVOP_VCALL ( op , CLBR_ANY ,
>PVOP_VCALL_CLOBBERS , VEXTRA_CLOBBERS , pre, post , ##
> This is written exactly as is in the D file. I still have to
> figure why this happens.
More information about the Digitalmars-d