2e8934be40
This required moving files around in the repository and shifting from a master.adoc structure to _topic_map.yml, etc. README and Makefile modified slightly to reflect new build process
36 lines
1.5 KiB
Text
36 lines
1.5 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 <<chap-Defensive_Coding-C>> apply.
|
|
|
|
In particular, the following Vala language constructs can result in
|
|
undefined behavior at run time:
|
|
|
|
* Integer arithmetic, as described in <<sect-Defensive_Coding-C-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 <<sect-Defensive_Coding-C-Pointers>>.
|
|
|
|
* 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 <<sect-Defensive_Coding-C-Use-After-Free>>).
|