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 <jessekphillip...@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.
