Re: [Vala] How to wrap select(2)'s fd_set?

["Michael 'Mickey' Lauer" <mickey vanille-media de>]

Am Friday 30 January 2009 08:30:43 schrieb Jürg Billeter:
> FdSet should be a struct, not a class, we do not need reference type
> semantics here. This eliminates unnecessary heap allocation. FD_ZERO
> should be bound as initialization method as it just zeroes the streuct.

Understood.

> [CCode (cname = "fd_set", cheader_filename = "sys/select.h"]
> public struct FdSet {
>     [CCode (cname = "FD_ZERO")]
>     public FdSet ();
>     ...
> }


With this change, I get a strange C-compilation error:

/local/pkg/fso/fso-gsm0710muxd/src/multiplexer.c: In 
Funktion »multiplexer_writefd«:
/local/pkg/fso/fso-gsm0710muxd/src/multiplexer.c:324: Fehler: expected 
expression before »do«
/local/pkg/fso/fso-gsm0710muxd/src/multiplexer.c:325: Fehler: expected 
expression before »do«
/local/pkg/fso/fso-gsm0710muxd/src/multiplexer.c:326: Fehler: expected 
expression before »do«

The respective generated code is:

gboolean multiplexer_writefd (Multiplexer* self, const char* command, gint fd) 
{
        fd_set _tmp0 = {0};
        fd_set readfds;
        fd_set _tmp1 = {0};
        fd_set writefds;
        fd_set _tmp2 = {0};
        fd_set exceptfds;
        struct timeval t = {(glong) 1, (glong) 0};
        gint r;
        gboolean _tmp3;
        gssize bwritten;
        g_return_val_if_fail (self != NULL, FALSE);
        g_return_val_if_fail (command != NULL, FALSE);
        readfds = (FD_ZERO (&_tmp0), _tmp0);
        writefds = (FD_ZERO (&_tmp1), _tmp1);
        exceptfds = (FD_ZERO (&_tmp2), _tmp2);
        FD_SET (fd, &writefds);
...

I have no idea where this 'do' comes from.

> > The code compiles, but emits two warnings:
> >
> > src/multiplexer.vala:162.13-162.75: warning: result variable type
> > incompatible with return type
>
> This warning is currently completely harmless. Vala prints this warning
> if you declare a local variable called `result' whose type is different
> from the return type of the method where the variable has been declared.
> The reason is that I am considering introducing an implicit `result'
> variable for the return value. This might be useful in some cases, for
> example, in connection with method postconditions.

I see, yes that will get interesting. I'll try changing my habits to 
use 'result' as a variable name :)

Thanks,

Mickey.