[Vala] No static arrays or typedefs in Vala?

[Walter Mundt <emage spamcop net>]

A friend and I have been experimenting with Vala, and trying to write  
VAPI bindings for a couple of C libraries, and we've run into a couple  
of issues that have gotten in the way.

The first and larger issue is this: does Vala have any support for  
C-style statically-allocated array types?  Without it, there're a  
couple of hacks we're looking at and wanting to avoid in the process  
of binding libraries that presume the use of this feature.

First scenario for issue 1: in one library, a C struct is defined that  
contains a byte array as a field, similar to this:

struct SomeStruct {
    // ... some members
    unsigned char buffer[1024];
    // ... some other members
};

Is there a way to declare a struct type in Vala that generates C code  
that looks like the above?  Declaring the member as "uchar* buffer" in  
a VAPI will allow Vala to generate code that compiles/works as long as  
the struct is declared in a pre-existing header.  However, this  
strikes me as an ugly and potentially-fragile hack.  Also, it would be  
nice to be able to declare such a struct in a .vala file and have it  
be processed into C like the above in case you want to build a  
structure like that without having the appropriate header handy, say,  
for transmission over a network.

Second scenario for issue 1: a different library uses a small set of  
typedefs for some standard array types; they look approximately as  
follows:

typedef float dVector3[4];
// ... several others follow with different names/sizes/dimensionalities

These are then used as function parameters.  Declaring these  
parameters as "[CCode(array_length=false)] float[] param" almost  
works, except:
(a) it's far less clear
(b) it does not convey the expected/required size of the array
(c) it does not allow you to use stack-allocated space for the values  
in function bodies, which can impose a performance penalty
(d) it makes it troublesome to maintain the bindings if any of the  
type definitions affected are changed, because those type names are  
nowhere reflected in the vapi file.

Now then, on to the second issue we encountered: the lack of a syntax  
like "typedef".  All we've seen are a lot of distributed vapi files  
that emulate this functionality through the use of  
'[CCode(cname="int")] struct our_int: int;'  However, this doesn't  
support array types (reference or static) or pointer types, and it  
doesn't really convey the intent all that well.  Is there anything  
better?

--
Walter Mundt
emage spamcop net