Converting Fuse headers

[Simen kjaeraas]

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 it is not zero-terminated, either append a '\0' to it, or, if
that can't or shouldn't be done, .dup it, and append a '\0' to
the copy.

If you have an immutable(char)[] (i.e. string), and you want to
change the contents of it, you should check your code. :p
In such a case, use char[] instead, and make sure to .dup any
literals, as those are placed in the static data segment and may
be write-protected.

If you have a string and you want to create a mutable copy, use .dup.

If some of the C functions expect a char*, check the documentation
to see if it should take a const(char)* instead.


> 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);
>
> [3]This is likely a big part of the problem, but I just didn't  
> understand the C. It is a defined as:
>
> #define fuse_main(argc, argv, op, user_data)				\
> 	fuse_main_real(argc, argv, op, sizeof(*(op)), user_data)
>
> But is called:
>
> return fuse_main(argc, argv, &hello_oper);
>
> And I can't find a three argument fuse_main. So I made one and just  
> passed a block of storage (converting to a pointer so the compiler  
> wouldn't complain of conversions and I didn't cast)

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.


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

All those functions manipulating the bitfield should be marked as
@property, btw.


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


> This used the is_hidden : 1 notation so I created some bit fields, but  
> it didn't have padding like the others, so I don't know if I did this  
> correctly.

Looks right to me.

-- 
Simen