Re: [Vala] About method overloading, constructor overloading and extension methods
Luca, seems nice to me.
Remember me the AspectJ:
aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}
But, of course, without the "pointcuts" and "voodoo syntax"
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] About method overloading, constructor overloading and extension methods
I'm all for extension methods, as long as they don't require too much
syntax, it's simple, there's as little magic as possible, don't break
things and are not invasive in the compiler.
Basically, we haven't decided the syntax yet.
In my opinion it should be as simple as this:
extend SomeClassName {
public void foo () { }
}
On Thu, May 15, 2014 at 8:37 PM, geovanisouz...@gmail.com <
geovanisouz...@gmail.com> wrote:
> Thank yout Evan, Luca and Aaron for explanation. I didn't see the archives
> for the historical debates. I agree with you.
>
> At all, with my experience with Python, the Zen says "explicit is better
> than implicit". The overload is a features that facilitate the programmer's
> life, but not the life of compiler maintainers...
>
> What about extensions methods? Already discussed or not implemented yet?
> The .NET Linq was brought to life based on it. Without EM (and generics, of
> course) Linq wouldn't possible.
>
> I imagine that Gee guys can help this discussion too.
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
--
www.debian.org - The Universal Operating System
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] About method overloading, constructor overloading and extension methods
Thank yout Evan, Luca and Aaron for explanation. I didn't see the archives for the historical debates. I agree with you. At all, with my experience with Python, the Zen says "explicit is better than implicit". The overload is a features that facilitate the programmer's life, but not the life of compiler maintainers... What about extensions methods? Already discussed or not implemented yet? The .NET Linq was brought to life based on it. Without EM (and generics, of course) Linq wouldn't possible. I imagine that Gee guys can help this discussion too. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] About method overloading, constructor overloading and extension methods
Hello, One of the reasons that Vala does not support method overloading is because it is meant to maintain c compatibility. If someone writes a library in Vala and the compiler starts coming up with naming schemes that can cause some issues for c users of the library (if the names don't make sense). This issue has been debated several times in the past and given the history I don't see it changing. Aaron Quoting Steven Oliver : That is a good question actually. I mean yannick's answer works in this overly-simplified case, but overall, is there a technical reason it doesn't work this way? Steven N. Oliver On Thu, May 15, 2014 at 2:06 PM, geovanisouz...@gmail.com < geovanisouz...@gmail.com> wrote: Sorry for my mistake. I used the same variable "result". Declaring: var result = add(2, 3); var result2 = add(1.2, 3.4); Worked fine. Thank you Yannick. But the discussion can continue. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] About method overloading, constructor overloading and extension methods
Also method overloading is the worst mistake a language could do. It's
tricky, it does not always work as the user expects, it has weird
semantics. Even if we didn't care about C naming, I would never implement
method overloading in a sane language.
On Thu, May 15, 2014 at 8:22 PM, Evan Nemerson wrote:
> On Thu, 2014-05-15 at 14:48 -0300, geovanisouz...@gmail.com wrote:
> > Hello guys,
> >
> > I'm thinking about the reasons behind the pseudo constructor overload,
> > method naming convensions and C# entension methods.
> >
> > I don't look deep in Vala compiler implementation, but can suggested
> > something to resolve this issue, based in what I see in generated C
> code: a
> > "name binder".
> >
> > Some kind of naming engine to rule 'em all, where the compiler can
> register
> > all found method names (with types, the complete signature), and from the
> > code writer can peek the C method names. For example, in the code:
> >
> > int add(int a, int b)
> > {
> > return a + b;
> > }
> >
> > int main(string[] args)
> > {
> > var result = add(2, 3);
> > print("Result: %d\n".printf(result));
> > return 0;
> > }
> >
> >
> > All works fine, and the resulting C code:
> >
> > gint add (gint a, gint b) {
> > gint result = 0;
> > gint _tmp0_ = 0;
> > gint _tmp1_ = 0;
> > _tmp0_ = a;
> > _tmp1_ = b;
> > result = _tmp0_ + _tmp1_;
> > return result;
> > }
> >
> >
> > gint _vala_main (gchar** args, int args_length1) {
> > gint result = 0;
> > gint _result_ = 0;
> > gint _tmp0_ = 0;
> > gchar* _tmp1_ = NULL;
> > gchar* _tmp2_ = NULL;
> > _tmp0_ = add (2, 3);
> > _result_ = _tmp0_;
> > _tmp1_ = g_strdup_printf ("Result: %d\n", _result_);
> > _tmp2_ = _tmp1_;
> > g_print ("%s", _tmp2_);
> > _g_free0 (_tmp2_);
> > result = 0;
> > return result;
> > }
> >
> >
> > int main (int argc, char ** argv) {
> > #if !GLIB_CHECK_VERSION (2,35,0)
> > g_type_init ();
> > #endif
> > return _vala_main (argv, argc);
> > }
> >
> >
> > Well, fine. But if I declare another method, like:
> >
> > float add(float a, float b)
> > {
> > return a + b;
> > }
> >
> >
> > The compiler forbid me.
> >
> > I know that the recomended way to solve this is use diferent names for
> > methods:
> >
> > float add_float(float a, float b)
> > {
> > return a + b;
> > }
> >
> > int add_int(int a, int b)
> > {
> > return a + b;
> > }
> >
> >
> > And again, all works.
> >
> > But, if this is the recommended way to make it work, why the compiler
> > itself doesn't do this for me? I would that this "naming binder" can
> expand:
>
> It is called mangling. See https://en.wikipedia.org/wiki/Name_mangling
>
> We don't do it because we care about the C API—libraries written in Vala
> are meant to be usable from other languages, which means providing a
> *good* C API. This simply can't be done automatically—the only way
> would be to force the user to choose the mangled names themselves, so
> you would end up with something like
>
> [CCode (cname = "add_float")]
> public float add (float a, float b);
> [CCode (cname = "add_int")]
> public int add (int a, int b);
>
> If you still have to provide the names yourself, the only "benefit" is
> that in Vala you can just use add (instead of add_float and add_int).
> The drawbacks include the Vala API being different from other languages
> and the code being more difficult to read and reason about.
>
> >
> > float add(float a, float b)
> > int add(int a, int b)
> >
> >
> > To something like this:
> >
> > gint add__int__int (gint a, gint b)
> > gfloat add__float__float (gfloat a, gfloat b)
> >
> >
> > Anyway, if the C compiler support overloading, why Vala does not?
>
> It doesn't. Vala targets C89, and C doesn't support overloading (well,
> generic selection) until C11. MSVC still doesn't support C99, let alone
> C11, and GCC doesn't support _Generic until 4.9 (which was just released
> about 3 weeks ago).
>
> > In case of extension methods, it can be expanded too, and only gain
> context
> > when included and used in source files. In C the
> > pseudo-object-oriented-programming is made passing the "this" (or in Vala
> > "self") variable to each function, thing made transparently by
> > compilers/runtimes of other languages.
> >
> > Extension methods is basically like C functions (receiving a "self"
> > reference) and mapped/validated by compiler when
> > "object.extension_method()" is used.
> >
> > So, which effort is necessary to make Vala compiler accept this feature?
> I
> > think that a centralized naming logic can help in these cases.
>
> Extension methods are tricky, but we could conceivably support them (see
> ). That said, there
> isn't any need for additional name mangling logic. The name can (and
> should) be generated based on the location of the extension method, not
> the object being extended.
>
>
> -Evan
>
> ___
> vala-list mailing list
> vala-lis
Re: [Vala] About method overloading, constructor overloading and extension methods
On Thu, 2014-05-15 at 14:48 -0300, geovanisouz...@gmail.com wrote:
> Hello guys,
>
> I'm thinking about the reasons behind the pseudo constructor overload,
> method naming convensions and C# entension methods.
>
> I don't look deep in Vala compiler implementation, but can suggested
> something to resolve this issue, based in what I see in generated C code: a
> "name binder".
>
> Some kind of naming engine to rule 'em all, where the compiler can register
> all found method names (with types, the complete signature), and from the
> code writer can peek the C method names. For example, in the code:
>
> int add(int a, int b)
> {
> return a + b;
> }
>
> int main(string[] args)
> {
> var result = add(2, 3);
> print("Result: %d\n".printf(result));
> return 0;
> }
>
>
> All works fine, and the resulting C code:
>
> gint add (gint a, gint b) {
> gint result = 0;
> gint _tmp0_ = 0;
> gint _tmp1_ = 0;
> _tmp0_ = a;
> _tmp1_ = b;
> result = _tmp0_ + _tmp1_;
> return result;
> }
>
>
> gint _vala_main (gchar** args, int args_length1) {
> gint result = 0;
> gint _result_ = 0;
> gint _tmp0_ = 0;
> gchar* _tmp1_ = NULL;
> gchar* _tmp2_ = NULL;
> _tmp0_ = add (2, 3);
> _result_ = _tmp0_;
> _tmp1_ = g_strdup_printf ("Result: %d\n", _result_);
> _tmp2_ = _tmp1_;
> g_print ("%s", _tmp2_);
> _g_free0 (_tmp2_);
> result = 0;
> return result;
> }
>
>
> int main (int argc, char ** argv) {
> #if !GLIB_CHECK_VERSION (2,35,0)
> g_type_init ();
> #endif
> return _vala_main (argv, argc);
> }
>
>
> Well, fine. But if I declare another method, like:
>
> float add(float a, float b)
> {
> return a + b;
> }
>
>
> The compiler forbid me.
>
> I know that the recomended way to solve this is use diferent names for
> methods:
>
> float add_float(float a, float b)
> {
> return a + b;
> }
>
> int add_int(int a, int b)
> {
> return a + b;
> }
>
>
> And again, all works.
>
> But, if this is the recommended way to make it work, why the compiler
> itself doesn't do this for me? I would that this "naming binder" can expand:
It is called mangling. See https://en.wikipedia.org/wiki/Name_mangling
We don't do it because we care about the C API—libraries written in Vala
are meant to be usable from other languages, which means providing a
*good* C API. This simply can't be done automatically—the only way
would be to force the user to choose the mangled names themselves, so
you would end up with something like
[CCode (cname = "add_float")]
public float add (float a, float b);
[CCode (cname = "add_int")]
public int add (int a, int b);
If you still have to provide the names yourself, the only "benefit" is
that in Vala you can just use add (instead of add_float and add_int).
The drawbacks include the Vala API being different from other languages
and the code being more difficult to read and reason about.
>
> float add(float a, float b)
> int add(int a, int b)
>
>
> To something like this:
>
> gint add__int__int (gint a, gint b)
> gfloat add__float__float (gfloat a, gfloat b)
>
>
> Anyway, if the C compiler support overloading, why Vala does not?
It doesn't. Vala targets C89, and C doesn't support overloading (well,
generic selection) until C11. MSVC still doesn't support C99, let alone
C11, and GCC doesn't support _Generic until 4.9 (which was just released
about 3 weeks ago).
> In case of extension methods, it can be expanded too, and only gain context
> when included and used in source files. In C the
> pseudo-object-oriented-programming is made passing the "this" (or in Vala
> "self") variable to each function, thing made transparently by
> compilers/runtimes of other languages.
>
> Extension methods is basically like C functions (receiving a "self"
> reference) and mapped/validated by compiler when
> "object.extension_method()" is used.
>
> So, which effort is necessary to make Vala compiler accept this feature? I
> think that a centralized naming logic can help in these cases.
Extension methods are tricky, but we could conceivably support them (see
). That said, there
isn't any need for additional name mangling logic. The name can (and
should) be generated based on the location of the extension method, not
the object being extended.
-Evan
signature.asc
Description: This is a digitally signed message part
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] About method overloading, constructor overloading and extension methods
That is a good question actually. I mean yannick's answer works in this overly-simplified case, but overall, is there a technical reason it doesn't work this way? Steven N. Oliver On Thu, May 15, 2014 at 2:06 PM, geovanisouz...@gmail.com < geovanisouz...@gmail.com> wrote: > Sorry for my mistake. I used the same variable "result". Declaring: > > var result = add(2, 3); > var result2 = add(1.2, 3.4); > > Worked fine. Thank you Yannick. > > But the discussion can continue. > ___ > vala-list mailing list > vala-list@gnome.org > https://mail.gnome.org/mailman/listinfo/vala-list > ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] About method overloading, constructor overloading and extension methods
Sorry for my mistake. I used the same variable "result". Declaring: var result = add(2, 3); var result2 = add(1.2, 3.4); Worked fine. Thank you Yannick. But the discussion can continue. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] About method overloading, constructor overloading and extension methods
G add(G a, G b)
{
if (a is int && b is int)
return (int) a + (int) b;
if (a is double && b is double)
return (double) a + (double) b;
return 0;
}
int main(string[] args)
{
var result = add(2, 3);
result = add(1.2, 3.4);
print("Result: %f\n".printf(result));
return 0;
}
Results in:
$ valac -C sample.vala
sample.vala:24.5-24.26: error: Assignment: Cannot convert from `double' to
`int'
result = add(1.2, 3.4);
^^
Compilation failed: 1 error(s), 0 warning(s)
I think that will not work. Generics without any condition (where, extends,
implements) is very tricky. Maybe creating a wrapper type or one C function
for each signature/types used...
--
@geovanisouza92 - Geovani de Souza
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] About method overloading, constructor overloading and extension methods
public G add (G a, G b) {}
and check the type of your numbers inside the function ? :)
2014-05-15 19:48 GMT+02:00 geovanisouz...@gmail.com <
geovanisouz...@gmail.com>:
> Hello guys,
>
> I'm thinking about the reasons behind the pseudo constructor overload,
> method naming convensions and C# entension methods.
>
> I don't look deep in Vala compiler implementation, but can suggested
> something to resolve this issue, based in what I see in generated C code: a
> "name binder".
>
> Some kind of naming engine to rule 'em all, where the compiler can register
> all found method names (with types, the complete signature), and from the
> code writer can peek the C method names. For example, in the code:
>
> int add(int a, int b)
> {
> return a + b;
> }
>
> int main(string[] args)
> {
> var result = add(2, 3);
> print("Result: %d\n".printf(result));
> return 0;
> }
>
>
> All works fine, and the resulting C code:
>
> gint add (gint a, gint b) {
> gint result = 0;
> gint _tmp0_ = 0;
> gint _tmp1_ = 0;
> _tmp0_ = a;
> _tmp1_ = b;
> result = _tmp0_ + _tmp1_;
> return result;
> }
>
>
> gint _vala_main (gchar** args, int args_length1) {
> gint result = 0;
> gint _result_ = 0;
> gint _tmp0_ = 0;
> gchar* _tmp1_ = NULL;
> gchar* _tmp2_ = NULL;
> _tmp0_ = add (2, 3);
> _result_ = _tmp0_;
> _tmp1_ = g_strdup_printf ("Result: %d\n", _result_);
> _tmp2_ = _tmp1_;
> g_print ("%s", _tmp2_);
> _g_free0 (_tmp2_);
> result = 0;
> return result;
> }
>
>
> int main (int argc, char ** argv) {
> #if !GLIB_CHECK_VERSION (2,35,0)
> g_type_init ();
> #endif
> return _vala_main (argv, argc);
> }
>
>
> Well, fine. But if I declare another method, like:
>
> float add(float a, float b)
> {
> return a + b;
> }
>
>
> The compiler forbid me.
>
> I know that the recomended way to solve this is use diferent names for
> methods:
>
> float add_float(float a, float b)
> {
> return a + b;
> }
>
> int add_int(int a, int b)
> {
> return a + b;
> }
>
>
> And again, all works.
>
> But, if this is the recommended way to make it work, why the compiler
> itself doesn't do this for me? I would that this "naming binder" can
> expand:
>
> float add(float a, float b)
> int add(int a, int b)
>
>
> To something like this:
>
> gint add__int__int (gint a, gint b)
> gfloat add__float__float (gfloat a, gfloat b)
>
>
> Anyway, if the C compiler support overloading, why Vala does not?
>
> In case of extension methods, it can be expanded too, and only gain context
> when included and used in source files. In C the
> pseudo-object-oriented-programming is made passing the "this" (or in Vala
> "self") variable to each function, thing made transparently by
> compilers/runtimes of other languages.
>
> Extension methods is basically like C functions (receiving a "self"
> reference) and mapped/validated by compiler when
> "object.extension_method()" is used.
>
> So, which effort is necessary to make Vala compiler accept this feature? I
> think that a centralized naming logic can help in these cases.
>
> Thank you.
>
> --
> @geovanisouza92 - Geovani de Souza
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] About method overloading, constructor overloading and extension methods
Hello guys,
I'm thinking about the reasons behind the pseudo constructor overload,
method naming convensions and C# entension methods.
I don't look deep in Vala compiler implementation, but can suggested
something to resolve this issue, based in what I see in generated C code: a
"name binder".
Some kind of naming engine to rule 'em all, where the compiler can register
all found method names (with types, the complete signature), and from the
code writer can peek the C method names. For example, in the code:
int add(int a, int b)
{
return a + b;
}
int main(string[] args)
{
var result = add(2, 3);
print("Result: %d\n".printf(result));
return 0;
}
All works fine, and the resulting C code:
gint add (gint a, gint b) {
gint result = 0;
gint _tmp0_ = 0;
gint _tmp1_ = 0;
_tmp0_ = a;
_tmp1_ = b;
result = _tmp0_ + _tmp1_;
return result;
}
gint _vala_main (gchar** args, int args_length1) {
gint result = 0;
gint _result_ = 0;
gint _tmp0_ = 0;
gchar* _tmp1_ = NULL;
gchar* _tmp2_ = NULL;
_tmp0_ = add (2, 3);
_result_ = _tmp0_;
_tmp1_ = g_strdup_printf ("Result: %d\n", _result_);
_tmp2_ = _tmp1_;
g_print ("%s", _tmp2_);
_g_free0 (_tmp2_);
result = 0;
return result;
}
int main (int argc, char ** argv) {
#if !GLIB_CHECK_VERSION (2,35,0)
g_type_init ();
#endif
return _vala_main (argv, argc);
}
Well, fine. But if I declare another method, like:
float add(float a, float b)
{
return a + b;
}
The compiler forbid me.
I know that the recomended way to solve this is use diferent names for
methods:
float add_float(float a, float b)
{
return a + b;
}
int add_int(int a, int b)
{
return a + b;
}
And again, all works.
But, if this is the recommended way to make it work, why the compiler
itself doesn't do this for me? I would that this "naming binder" can expand:
float add(float a, float b)
int add(int a, int b)
To something like this:
gint add__int__int (gint a, gint b)
gfloat add__float__float (gfloat a, gfloat b)
Anyway, if the C compiler support overloading, why Vala does not?
In case of extension methods, it can be expanded too, and only gain context
when included and used in source files. In C the
pseudo-object-oriented-programming is made passing the "this" (or in Vala
"self") variable to each function, thing made transparently by
compilers/runtimes of other languages.
Extension methods is basically like C functions (receiving a "self"
reference) and mapped/validated by compiler when
"object.extension_method()" is used.
So, which effort is necessary to make Vala compiler accept this feature? I
think that a centralized naming logic can help in these cases.
Thank you.
--
@geovanisouza92 - Geovani de Souza
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] A brand new build system
Sounds like a good case for autovala: https://github.com/rastersoft/autovala/ cheers, Max. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] A brand new build system
Thank you Steve, I don't had see it. I'll take a look. Geovani @ Android ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] A brand new build system
Hello Vala guys! I would to thank you for this amazing language. I knew it yesterday, and love it yet! But, I noticed that have a lot of things to do, to turn it a great tool. For example, a *new simplified build system*. Not that I don't like Autotools and Make, but the language itself simplifies the C programming, so, why use a jurasic and complicated (for newbies) build system? I'm thinking how to solve this problem, and would like to share with you some ideas. We could make the dependency management and build with only one simple file: The Valafile. I made a draft of it: # The knew dependencies pkg "gio" pkg "gee", version: "0.8" # Some nice git depencies git "antono/valum" # default point to github.com git "lorem/ipsum", origin: "gitorius.org" # Some C dependencies include "foo/include/" lib "libwhatever.so" # Build profiles build "src/main" # Or build "src/main", bin: "my_program" # output build/my_program # Other build types build "src/lib", lib: "my_lib" # outputs build/libmy_lib.so build "src/web", web: "my_web_api", deploy: "destiny" # Sample Apache deploy deploy "destiny", remote: "127.0.0.1", kind: "mod_fcgi", root: "/wwwroot/my_web_api" publish "geovanisouza92/sample" # In some online package manager like RubyGems.org To handle this file, I think that we can make a new command-line tool, to execute like: # Create a new project with structure: # project_name # build/ # Can be ignored and deleted anytime # libs/ # src/ # main/ # test/ # main/ # vapi/ vala new # Install dependencies and download libs from Valafile vala install # Execute compiling and linking for each build target vala build # Build a single build target vala build my_program # Generate docs vala docs # Generate .vapi files vala vapi # Pack and publish the project in "vala.org" package manager # Maybe sign with GPG? vala bundle vala publish # Deploy all targets vala deploy # Deploy a single target vala deploy my_web_api As you can see, I think that a "recommended project structure" can be interesting, as well a coding-standard. We can have a "vala.org" (or other site) to host libraries and docs, to help comunity to grow up. As can you imagine, I'm very excited with Vala, and can sound like a Ruby-comunity-boy. In fact, I am. But, Vala demonstrate a powerful way to program C friendly, and I think that I can help too. Thank you for reading. -- @geovanisouza92 - Geovani de Souza ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Memory safety
On 05/15/2014 03:52 PM, Al Thomas wrote:
Is there a bug report for this with more details?
Not yet, it's not clear if you'd consider it a bug.
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.
It seems it comes from glib-2.0.vapi. The compiled C code looks like this:
static gchar string_get (const gchar* self, glong index) {
gchar result = '\0';
glong _tmp0_;
gchar _tmp1_;
g_return_val_if_fail (self != NULL, '\0');
_tmp0_ = index;
_tmp1_ = ((gchar*) self)[_tmp0_];
result = _tmp1_;
return result;
}
So there isn't any range checking. It's actually somewhat
understandable, considering that range checking for NUL-terminated
strings can move code to a different complexity class.
The function I had encountered initially, string.substring, does not
implement full range checking, either.
The GLib string builder function (
http://references.valadoc.org/#!api=glib-2.0/GLib.StringBuilder ) is
also recommended for use in Vala.
StringBuilder doesn't do any arithmetic, so it inherits the safety
properties of the underlying C implementation.
--
Florian Weimer / Red Hat Product Security Team
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Memory safety
> 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
Re: [Vala] Memory safety
do you think that in a code like:
void func() {
uint64[] output = new uint64[1]; // return callback
GLib.Timeout.add( 1000,
() => {
output[0]=1;
return false;
}
);
}
I have to check if output is still valid?
regards
2014-05-15 10:22 GMT+02:00 Luca Bruno :
> On 15/05/2014 10:18, Florian Weimer wrote:
>
>> Hi,
>>
>> am I correct in assuming that Vala is supposed to inherit the lack of
>> memory safety from C? Or put differently: If there is Vala code that does
>> not guard callers from memory safety violations but it could do so, this is
>> not a problem because callers are generally expected to fulfill such
>> (implicit) preconditions.
>>
>> 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.
> For example:
> 1. func1(): create a local array
> 2. Call async func2(array) without waiting the function to finish
> 3. Return from func1
> 4. func2 runs with a dangling pointer to the array
>
> Vala is not free of rough edges, it makes your life easier. But since a
> Vala array is a standard C array, it can't be referenced counted and that's
> why you get the above (unwanted from a newbie perspective) behavior.
>
> Best regards
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Memory safety
On 05/15/2014 10:22 AM, Luca Bruno wrote: am I correct in assuming that Vala is supposed to inherit the lack of memory safety from C? Or put differently: If there is Vala code that does not guard callers from memory safety violations but it could do so, this is not a problem because callers are generally expected to fulfill such (implicit) preconditions. 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 ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Memory safety
On 15/05/2014 10:18, Florian Weimer wrote: Hi, am I correct in assuming that Vala is supposed to inherit the lack of memory safety from C? Or put differently: If there is Vala code that does not guard callers from memory safety violations but it could do so, this is not a problem because callers are generally expected to fulfill such (implicit) preconditions. 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. For example: 1. func1(): create a local array 2. Call async func2(array) without waiting the function to finish 3. Return from func1 4. func2 runs with a dangling pointer to the array Vala is not free of rough edges, it makes your life easier. But since a Vala array is a standard C array, it can't be referenced counted and that's why you get the above (unwanted from a newbie perspective) behavior. Best regards ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Memory safety
Hi, am I correct in assuming that Vala is supposed to inherit the lack of memory safety from C? Or put differently: If there is Vala code that does not guard callers from memory safety violations but it could do so, this is not a problem because callers are generally expected to fulfill such (implicit) preconditions. Is this documented somewhere? Thanks, Florian -- Florian Weimer / Red Hat Product Security Team ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
