36 lines
1.8 KiB
Text
36 lines
1.8 KiB
Text
|
|
:experimental:
|
|
|
|
[[chap-Defensive_Coding-Vala]]
|
|
= The Vala Programming Language
|
|
|
|
Vala is a programming language mainly targeted at GNOME developers.
|
|
|
|
Its syntax is inspired by C# (and thus, indirectly, by Java). But
|
|
unlike C# and Java, Vala does not attempt to provide memory safety:
|
|
Vala is compiled to C, and the C code is compiled with GCC using
|
|
typical compiler flags. Basic operations like integer arithmetic
|
|
are directly mapped to C constructs. As a results, the
|
|
recommendations in xref:../programming-languages/C.adoc#chap-Defensive_Coding-C[Defensive Coding in C] apply.
|
|
|
|
In particular, the following Vala language constructs can result in
|
|
undefined behavior at run time:
|
|
|
|
* Integer arithmetic, as described in xref:../programming-languages/C-Language.adoc#sect-Defensive_Coding-C-Arithmetic[Recommendations for Integer Arithmetic].
|
|
|
|
* Pointer arithmetic, string subscripting and the
|
|
`substring` method on strings (the
|
|
`string` class in the
|
|
`glib-2.0` package) are not range-checked. It
|
|
is the responsibility of the calling code to ensure that the
|
|
arguments being passed are valid. This applies even to cases
|
|
(like `substring`) where the implementation
|
|
would have range information to check the validity of indexes.
|
|
See xref:../programming-languages/C-Language.adoc#sect-Defensive_Coding-C-Pointers[Recommendations for Pointers and Array Handling]
|
|
|
|
* Similarly, Vala only performs garbage collection (through
|
|
reference counting) for `GObject` values. For
|
|
plain C pointers (such as strings), the programmer has to ensure
|
|
that storage is deallocated once it is no longer needed (to
|
|
avoid memory leaks), and that storage is not being deallocated
|
|
while it is still being used (see xref:../programming-languages/C-Allocators.adoc#sect-Defensive_Coding-C-Use-After-Free[Use-after-free errors]).
|