ciechowoj

Hmm, it should have been translated to `_IOR!uint('o', 70)`. I'll take a look when I have some spare time. Actually, can you share the full dstep invocation that you've used...

Yes, this is surprising. Maybe _IOR and _IOW's are build-in in the gcc in linux and corresponding headers aren't explicitly included? (I remember there was something strange with regard to...

Ah, it's on D-side. If you have some time you can try to temporarily include the ioctl header. You can try to import https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/ioctl.d in D code as well but...

> I had to change all the _IOx to _IOx!… to remove the third argument where it was. Also there are a number of cross module references that had to...

How does any other code that DStep cannot translate is treated? Can't we just ignore the blocks?

We would need to include the file with the structure representing the block along with the output files...

I think we could emit additional file with name something like `dstep.d` and import it from the translated one, in `dstep.d` there would be required code. Another idea is to...

> Out of curiosity, in C, how do you access the anonymous field/member, if possible? I believe this is padding. On Jun 14, 2017 08:50, "jacob-carlborg" wrote: > BTW, it's...

Yeah, I reproduced the issue, so it isn't only your setup.

Ok, so the problem is "cram/cram.h" contains only include files, and no declarations and dstep translates only the content of the *exact* input file and nothing else. In your case...