Re: [Vala] Memory safety

[Florian Weimer <fweimer redhat com>]

On 05/15/2014 03:52 PM, Al Thomas wrote:

> Is there a bug report for this with more details?

Not yet, it's not clear if you'd consider it a bug.

> I would say in general Vala/Genie attempts to be safer than C, within
> the limits of a language that compiles to C code.
>
> Vala strings are UTF8 encoded gchar, but the length and indices are in
> bytes. See https://wiki.gnome.org/Projects/Vala/StringSample
>
> A program such as:
>
> void main () {
>      string a = "hello";
>      char b = a[100];
>      print ( b.to_string() );
>      print ( ((int) b).to_string());
>      }
>
> will compile and the C code generated uses the line
>
>       _tmp1_ = string_get (a, (glong) 100);
>
> to get the index. I'm not sure where string_get function comes from, but
> the output is a zero byte for an out of range index.

It seems it comes from glib-2.0.vapi.  The compiled C code looks like this:

static gchar string_get (const gchar* self, glong index) {
        gchar result = '\0';
        glong _tmp0_;
        gchar _tmp1_;
        g_return_val_if_fail (self != NULL, '\0');
        _tmp0_ = index;
        _tmp1_ = ((gchar*) self)[_tmp0_];
        result = _tmp1_;
        return result;
}

So there isn't any range checking.  It's actually somewhat 
understandable, considering that range checking for NUL-terminated 
strings can move code to a different complexity class.

The function I had encountered initially, string.substring, does not 
implement full range checking, either.

> The GLib string builder function (
> http://references.valadoc.org/#!api=glib-2.0/GLib.StringBuilder ) is
> also recommended for use in Vala.

StringBuilder doesn't do any arithmetic, so it inherits the safety 
properties of the underlying C implementation.

--
Florian Weimer / Red Hat Product Security Team