After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 610083 - SimpleType code generation broken
SimpleType code generation broken
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Structs
unspecified
Other All
: High normal
: 1.0
Assigned To: Vala maintainers
Vala maintainers
: 741466 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-02-16 09:58 UTC by Sebastian Dröge (slomo)
Modified: 2018-05-22 13:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix for SimpleType creation method code generation (3.93 KB, patch)
2012-03-31 20:34 UTC, Nathan Summers
none Details | Review

Description Sebastian Dröge (slomo) 2010-02-16 09:58:16 UTC
Hi,
the code generation for SimpleTypes is broken. Take as example the following:

[SimpleType]
[Immutable]
[CCode (copy_function = "fraction_copy")]
struct Fraction {
  public int num;
  public int den;

  public Fraction copy () {
    return Fraction (num, den);
  }

  public Fraction (int num, int den) {
    this.num = num;
    this.den = den;
  }

  public Fraction mult (Fraction other) {
    return Fraction (num * other.num, den * other.den);
  }
}


Some errors in the generated code are:

void fraction_init (Fraction self, gint num, gint den): This initializes self, but as self is passed by value this has absolutely no effect. It should either be passed by reference for that function or should be returned. Code that uses fraction_init() expect that it returns the initialized instance and that it only takes the num/den parameters and not the self parameter.
In fraction_init(), self is simply passed to memset while the address of it should be passed.

I'll try to create a patch for this to work later.
Comment 1 Sebastian Dröge (slomo) 2010-02-16 12:15:57 UTC
So, how should the init function look like?

void fraction_init (Fraction *f, gint num, gint den);
or
Fraction fraction_init (gint num, gint den);

The latter should probably be called fraction_new() though.
Comment 2 zarevucky.jiri 2010-02-16 12:37:12 UTC
Perhaps you're looking at it from the wrong side. Should SimpleType have any init function at all? For me, it doesn't make much sense.

Why use SimpleType anyway? It's for bindings. I don't see any advantages.
Comment 3 Sebastian Dröge (slomo) 2010-02-16 14:51:58 UTC
(In reply to comment #2)
> Perhaps you're looking at it from the wrong side. Should SimpleType have any
> init function at all? For me, it doesn't make much sense.

Well, in my example it makes sense, no? :)

> Why use SimpleType anyway? It's for bindings. I don't see any advantages.

Because instances are passed by value. Normal structs are passed by reference.
Comment 4 Sebastian Dröge (slomo) 2010-02-16 16:02:32 UTC
Jürg said on IRC, that he would probably prefer

Fraction fraction(gint num, gint den)

(other constructors would be Fraction fraction_from_double (gint num, gint den) then for example).

This is similar to time_t time() then.
Comment 5 Luca Bruno 2010-12-23 22:08:38 UTC
A construction function in this case should work like with classes, not like struct init as slomo said, and it makes sense to me.
Comment 6 Nathan Summers 2012-03-31 20:34:02 UTC
Created attachment 211043 [details] [review]
Fix for SimpleType creation method code generation

I ran into this bug too, and coded a fix for it.
Comment 7 Sebastian Dröge (slomo) 2013-07-17 13:26:31 UTC
Ping? There's a patch now :)
Comment 8 Rico Tzschichholz 2017-03-09 21:37:06 UTC
*** Bug 741466 has been marked as a duplicate of this bug. ***
Comment 9 GNOME Infrastructure Team 2018-05-22 13:28:52 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/72.