[PATCH] Use long instead of int when retrieving DIVE_DATE via gtk_tree_model_get

Linus Torvalds torvalds at linux-foundation.org
Wed Sep 19 16:12:29 PDT 2012


On Wed, Sep 19, 2012 at 3:38 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> From: "Lubomir I. Ivanov" <neolit123 at gmail.com>
>
> diveslit.c:date_data_func()
>
> When requesting gtk_tree_model_get() to write to a local variable
> deep inside the gtk function implementation in question (GLib), there are
> not much safety checks to warn if our passed variable to the vararg list
> is of the correct type, which is unlike gtk_tree_model_get_value(),
> which will report typed errors.


Ack. DIVE_DATE is declared to be of type G_TYPE_LONG, and passing in
an "int *" to it will overwrite random memory next to the int on when
compiled for a LP64 model.

And most of the time nobody noticed, because it depends on the stack
layout etc, and most stack slots are aligned to "long" anyway, so on a
little-endian machine it all "just works".

We have a number of places where we use "time_t", which is also wrong.
Sure, on Linux (at least x86) it is the same size as long both in
32-bit and 64-bit modes, but it's still wrong. It wouldn't be
unreasonable to have a 64-bit time_t and a 32-bit "long" (or vice
versa, although that's some pure crazy right there - but I know OSF/1
on alpha did that).

So we should always use "long", since that's how that thing is
declared, and then assign the result to a time_t afterwards.

Ugh. This is something that a static checker could easily do and
inform us about when we have a bug like this, but as you say, varargs
tends to lose all the type-checking. Argh.

             Linus


More information about the subsurface mailing list