Re: [Vala] Vala thinks uint32 constant is int64

[Evan Nemerson <evan coeus-group com>]

On Wed, 2010-11-24 at 02:56 +0100, Jaroslav Šmíd wrote:
> On 11/19/2010 10:15 PM, Evan Nemerson wrote:
> > On Fri, 2010-11-19 at 19:58 +0100, Jaroslav Smid wrote:
> > > Well, U suffix works, but I thought vala would be smart enough to handle
> > > this. Anyway, I had to switch to C because vala doesn't use size_t for array
> > > sizes and uses int.
> >
> > public void foo ([CCode (array_length_type = "size_t")] int[] bar);
> >
> > Generally array_length_type is used for bindings... if you just need to
> > use a C library which uses size_t you can just do something like the
> > above in your vapi and it will work perfectly. Lots of bindings use this
> > since the type used for the array length in C is so inconsistent (often
> > even within the same library).
> >
> > If you want libraries you write in Vala to expose size_t as the array
> > length parameter, you can still do it but you will occasionally have to
> > work around issues caused by Vala thinking the variable is an int
> > (although it will be generated as size_t). That wouldn't be too
> > difficult, though... certainly less work than writing everything in C.
> >
> > > pancake: sorry for sending messed up message :-)
> > >
> > > On Thu, Nov 18, 2010 at 10:53 PM, pancake<pancake youterm com>  wrote:
> > >
> > > > Vala should handle this correctly. The type is uint32 and not int32
> > > >
> > > > On 18/11/2010, at 15:31, Xavier Bestel<xavier bestel free fr>  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > On Thu, 2010-11-18 at 10:52 +0100, Jaroslav Smid wrote:
> > > > > > /home/jardik/Projects/DAOLinux/ErfEditor/Blowfish.vala:6.15-6.24: error:
> > > > > > Expected initializer of type `uint32' but got `int64'
> > > > > >         0x243F6A88, 0x85A308D3, 0x13198A2E, 0x03707344,
> > > > > >                     ^^^^^^^^^^
> > > > >
> > > > > I think it's because this constant is too big to fit a signed int32, so
> > > > > it's a signed int64 =>  error.
> > > > > You should suffix it to explicitly tell it's unsigned to make it fit, I
> > > > > guess.
> > > > >
> > > > >        Xav
>
> Anyway, any chance that vala will switch to size_t (or at least intptr_t 
> or ptrdiff_t (which is standard defined type for pointer difference)) 
> from int for array indexing and array sizes?

It's a long shot. The problem is that Vala isn't building a whole new
ecosystem of software, it is trying to reuse existing libraries. It is
easy to switch to size_t (or ssize_t) if you're creating, say, .NET or
JRE, but most C libraries use int.

> Writing that stuff before each array is very ugly.

I agree that it is ugly, but unless you can convince all the C libraries
to switch to (s)size_t, I don't see a way around it. You either have to
write something extra when you want to use size_t or when you want to
use int, and I think int is by far the most common case so it makes
sense to optimize for that.

> At least some command line argument that would 
> force vala to use size_t? I know languages like C# and Java use int - 
> but that is what I don't get. It's much better if type with the size of 
> a pointer is used for it,

A command line switch would be *horrible*. Then you would have something
that completely alters the behavior of the compiler in a quite possibly
incompatible way that would be very difficult to spot. Every time you
get a chunk of Vala code, you have to know whether array lengths need to
be int or size_t... Then what happens when you need to mix the two in
the same project?

Also, keep in mind that not everyone is going to agree on size_t. First
of all, it's unsigned, and there are a lot of places where that is a
deal-breaker. Then, what about ssize_t, unsigned int, unsigned long,
long, unsigned short, short, intptr_t, ptrdiff_t, etc.?

The only thing I think valac should be doing is be to handle something
like this properly:

void foo ([CCode (array_length_type = "size_t")] uint8[] bar) {
  var baz = bar.length;
}


-Evan