> 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 _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
