The problem is that Vala uses pointers to stores ints. It is both valid C and 64-bit safe.

If you still consider it a bug please fill it under Vala (I have no way of fixing it in libgee) but I don't think generating warning-free code would be their goal. Warnings are quite useful for programmers I don't think they are as useful in generated code.

PS.I develop and test code on 64-bit machine so 64-bit compatibility is better supported then 32-bit.

Really?

warning: assignment makes pointer from integer without a cast => This is not considered an issue?

I reported a bunch of such issues on different projects an in every case it was fixes in the vala code... only in the VERY early days of vala was it really vala issues.

(In reply to comment #2)
> Really?
> 

Really. 

> warning: assignment makes pointer from integer without a cast => This is not
> considered an issue?
> 

No as it is not a real pointer but a generic placeholder (i.e. in code it is represented by G).
For example one of the warnings corresponds to following code:

static gboolean ____lambda25_ (void) {
        gboolean result = FALSE;
        GThread* _tmp0_ = NULL;
        _tmp0_ = g_thread_self ();
        g_thread_set_priority (_tmp0_, G_THREAD_PRIORITY_LOW);
        while (TRUE) {
                g_thread_yield ();
                gee_hazard_pointer_release_policy_attempt_free ();
        }
        return result;
}


static gpointer _____lambda25__gthread_func (gpointer self) {
        gpointer result;
        result = ____lambda25_ ();
        return result;
}


The Vala code is:

                                        Thread.create<bool> (() => {
                                                Thread.self<bool> ().set_priority (ThreadPriority.LOW);
                                                while (true) {
                                                        Thread.yield ();
                                                        attempt_free ();
                                                }
                                        }, false);

It's line 451 in gee/hazardpointer.vala if you want to look it up. The result is an integer (to be more exact - boolean) that is part of generic and returned as generic.

Another example is:

static gint __lambda2_ (CollectionTests* self, gchar* x, gint y) {
        gint result = 0;
        gint _tmp0_;
        g_return_val_if_fail (x != NULL, 0);
        _tmp0_ = y;
        result = _tmp0_ + 1;
        _g_free0 (x);
        return result;
}


static gpointer ___lambda2__gee_fold_func (gpointer g, gpointer a, gpointer self) {
        gpointer result;
        result = __lambda2_ (self, g, a);
        return result;
}

Which corresponds to (line 776 in tests/testcollection.vala):

count = test_collection.iterator ().fold<int> ((x, y) => {return y + 1;}, 0);

The actual type of fold is:

        public delegate A FoldFunc<A, G> (owned G g, owned A a);
        public virtual A fold<A> (FoldFunc<A, G> f, owned A seed);

and it the line 776 have corresponding code like (test/testcollections.c line 2660):

        _tmp9_ = gee_traversable_fold ((GeeTraversable*) _tmp8_, G_TYPE_INT, NULL, NULL, ___lambda2__gee_fold_func, self, (gpointer) ((gintptr) 0));

As I said POINTER (32 or 64 bits)  is used to store an INTEGER (32 bits)[1] - not vice versa.

[1]  Which even if not legal is used by existsing code in GLib by GINT_TO_POINTER and GPOINTER_TO_INT)

> I reported a bunch of such issues on different projects an in every case it was
> fixes in the vala code... only in the VERY early days of vala was it really
> vala issues.

It is neither - other then missing cast to tell the compiler "yes I really know what I am doing" - which is not mandated by C.

(In reply to comment #3)
> [1]  Which even if not legal is used by existsing code in GLib by
> GINT_TO_POINTER and GPOINTER_TO_INT)

And those macros are using casts to achieve this. Vala should do the same.

With the current Vala version, gee compiles without warnings on C level.