Re: [Vala] Memory safety

[Al Thomas <astavale yahoo co uk>]

> Vala inherits the problem of C, yes. You could certainly do some evil
>
> > casts like in C. Vala however is certainly safer than C in many aspects,
> > in other aspects however you have to know what you are doing and how
> > Vala compiles down to C in certain cases.
>
> Okay, good to know.  I asked because some of the offset/lengths check in 
> the glib string library are a bit … off, and they can trigger C integer 
> overflow, which is undefined.  But if Vala is general unsafe in this 
> sense, it may not be necessary to fix these instances (it would be 
> painful anyway because this code isn't in a dynamically linked).
>
> -- 
> Florian Weimer / Red Hat Product Security Team
>
> Is there a bug report for this with more details?

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.

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

So I think your question raises some interesting questions about how Vala programmers should handle strings 
securely to avoid buffer and integer overflows for a robust application. It would be nice to gather some 
ideas on this. Maybe for starters http://www.and.org/vstr/security

Regards,

Al Thomas