Re: [Vala] using a non-glib C library in vala

["Michael B. Trausch" <mbt zest trausch us>]

On Wed, 2009-09-16 at 21:34 +0200, Jan Hudec wrote:
> [...]
> > However, there is one small problem:  You can *not* use the structure as
> > a [SimpleType], due to a bug in Vala (see bug 588280).  If you attempt
>
> Why do you think it is a [SimpleType]. SimpleTypes are only the built-in
> non-structured types (int, char, float...) or anything typedefed to them
> (size_t, ssize_t, time_t...). Anything defined using the struct keyword is
> not one.

Did the meaning of [SimpleType] change somewhere?  I thought it meant
"pass by value".  Otherwise, pointers are used in the generated C code.
It causes some strange issues without some trickery (though Jürg helped
me out at one point figuring out how to do that, with the X bindings and
something else).

If what you're saying is true, though, that would mean that there is no
way to do certain things that are often done in C.

> > to do so, Vala will generate an incorrect .c code file to feed to gcc,
> > and gcc will (correctly) error out, stating that memset was not passed
> > enough parameters.  This was deemed to be not a problem, though in my
> > personal opinion, Vala should either throw an error or generate correct
> > C code, not generate incorrect C code to be fed to the compiler.
> >
> > However, I don't know how to fix the issue in valac, so I can't really
> > reopen the bug.  Just keep in mind that using a SimpleType-decorated
> > struct is impossible in Vala, even if that is what you would do in C.
>
> Vala should not generate invalid code, but this bug is indeed invalid as
> described.

The bug is "memset code generation is incorrect", so I'm not sure how
you can say "Vala should not generate invalid code, but this bug is
indeed invalid".  The bug is that the code generation is incorrect.

Whether or not the binding that triggers the incorrect code generation
is itself incorrect is another, distinct issue.  If it is indeed
incorrect, then there should be a Vala compiler diagnostic to catch it.
So, if what you're saying is correct, that bug report really contains
*two* valid bugs, one that isn't actually described, and the one that is
(invalid code generation).

        --- Mike

-- 
Blog:  http://mike.trausch.us/blog/
Misc. Software:  http://mike.trausch.us/software/