Hi Tal,
On Tue, 2014-01-07 at 07:46 +0200, Tal Hadad wrote:
The user might use ar varible later and it will crush he's application.
If he was lucky enough, he would realize that ar is null.
It's not easy to find that this line causing it.
Risking dangling pointers is much worse than null
On 07/01/2014 06:46, Tal Hadad wrote:
This case trigger me a question I wanted to ask before.
Why transforming ownership is nulling the original variable?
Instead of nulling, maybe just change variable to behave as unowned.
You might say that there is a problem in my solution, like this code:
On 07/01/2014 15:51, Michele Dionisio wrote:
Hi I'm working not with valac 0.22.
building with
--enable-experimental-non-null
there is no way to define
private const GLib.OptionEntry[] options = {
// --version
{ version, 0, 0, OptionArg.NONE, ref version,
Hi I'm working not with valac 0.22.
building with
--enable-experimental-non-null
there is no way to define
private const GLib.OptionEntry[] options = {
// --version
{ version, 0, 0, OptionArg.NONE, ref version, Display version
number, null },
//
sorry how I can do that?
2014/1/7 Luca Bruno lethalma...@gmail.com
On 07/01/2014 15:51, Michele Dionisio wrote:
Hi I'm working not with valac 0.22.
building with
--enable-experimental-non-null
there is no way to define
private const GLib.OptionEntry[] options = {
//
You have to change the glib-2.0.vapi distributed with vala. We as
maintainers should also fix that I guess.
On Tue, Jan 7, 2014 at 4:08 PM, Michele Dionisio michele.dioni...@gmail.com
wrote:
sorry how I can do that?
2014/1/7 Luca Bruno lethalma...@gmail.com
On 07/01/2014 15:51, Michele
