Re: [Vala] Vala thinks uint32 constant is int64

[Jan Hudec <bulb ucw cz>]

On Tue, Nov 23, 2010 at 18:36:40 -0800, Evan Nemerson wrote:
> On Wed, 2010-11-24 at 02:56 +0100, Jaroslav Šmíd wrote:
> > 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.

Standard library uses size_t consistently and so does anything POSIX.

GLib does use it's own typedef gsize, but does not do so consistently. The
memory functions do, but the rest is a mixture.

In any case I would prefer if vala generated size_t in interfaces it
*generates* and was able to understand appropriate declarations for .vapis.

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

There is a way around it -- being able to specify per-namespace default.
A single library is usually self-consistent. So specifying the attribute for
whole namespace would help. 

So if you have a library that uses type X consistently, you'd just annotate
the top-level namespace declaration in the .vapi with
[CCode(array_size_type = "X")] and be done with it. If it's not
self-consistent, than obviously individual members and arguments would need
to be annotated.

> A command line switch would be *horrible*.

Agree. Command-line switch would not work.

> 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 precise meaning of size_t, ptrdiff_t and inptr_t are defined by the
standard, so there is a clear guideline when to use which (I don't think
ssize_t is a standard type). They are:

 - size_t is the return type of sizeof operator and used as argument of
   memory allocation functions, so it's appropriate for array and object
   sizes.

 - ptrdiff_t is the return type of operator - applied to pointers, so it's
   appropriate for offsets that need to be signed.

 - intptr_t (c99 only) is an integeral type large enough to store value of
   a void*.

Note, that size_t or ptrdiff_t don't have to be large enough to store value
of a void*. size_t and ptrdiff_t must only be able to store size of any
single object, but single objects may be limited to less than whole memory
size (e.g. when segments are used).

-- 
                                                 Jan 'Bulb' Hudec <bulb ucw cz>