Converting Fuse headers

[Jesse Phillips]

Simen kjaeraas Wrote:

> > The last one is the node structure[5]. Which I found in fuse.c[6] but  
> > seems to be used a lot so I don't no why it isn't in a header.
> 
> Lemme guess, usually just the pointer is used? If so, it's hiding the
> implementation. Just an indication you should never need to touch the
> innards of the node.

Thank you so much. This is the only one I have a follow up question. I'm going to test this question when I get home, but just in case it doesn't work.

In the header file it declares two structures. On of them being fuse

/** Handle for a FUSE filesystem */
struct fuse;

Can you forward declare a reference like this in D? If not does it matter what I define it to be?

struct fuse {} // Since I'm really only passing pointers to this anyway.

Sure hope this makes it work.

> Jesse Phillips <jessekphillips+D at gmail.com> wrote:
> 
> > hello_str = cast(char*) toStringz("Hello World!\n");
> >
> > I stopped doing this, but I'm just wondering how you could get a  
> > modifiable C string if I needed one?
> 
> If you already have a char[], just make sure it's terminated with
> a zero ('\0') character, and you can use yourCharArray.ptr to get
> the char*.
...
> If some of the C functions expect a char*, check the documentation
> to see if it should take a const(char)* instead.
 
Thanks, I had been using ".".dup.ptr in a couple places so, I was a little bit iffy then realized const(char*) actually worked for most of them. Otherwise I don't want to assume the parameter is const.

> 
> > fuse.d:669 auto user_data = new ubyte[78];
> > fuse.d:670 return fuse_main_real(cast(int) argc, argv, op,  
> > (*(op)).sizeof, user_data.ptr);
> 
> All other places I've looked seem to add a NULL at the end. Could be
> that's done automagically otherwise, but I would not bet on it.

Thanks. I don't know why I thought I should give it data.

> 
> > Then there is a structure which had some padding, and htod didn't fully  
> > convert it, leaving off two fields at the end[4]. Maybe I should move  
> > them to just after the bit field? I think it would be fine...
> 
> My guess is it somehow got confused by the bitfield. Should be fine just
> adding it as you say.

Yeah, thinking about it some, I don't know how functions affect the structure, so I'll move the fields before the functions.