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 688142 - Should be error when method with [ReturnsModifiedPointer] is called from unowned variable
Should be error when method with [ReturnsModifiedPointer] is called from unow...
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: general
unspecified
Other All
: High normal
: 1.0
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-12 07:18 UTC by Tal
Modified: 2018-05-22 14:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tal 2012-11-12 07:18:24 UTC
There should be warning(maybe error) when method with [ReturnsModifiedPointer] is called from unowned variable.

Take a look on GLib.SList. The beginner programmer(me too) can be assign an unowned variable to the list, and remove items, but he don't know it shell update the owned pointer.

Example:

unowned GLib.SList list = given_list;
list.remove(data);

Naive programmers can be fooled(like me) that this code are valid,
since Vala print no errors neither warning.

Also, what will happen if GLib.SList takes ownership without passing ownership?
It should duplicate GLib.SList with "dup_func", but should it duplicate the whole list, or just this item? Same bug can be reproduced when two variables owning same list item.

I think that for fixing up the second bug, you shell remove the auto "dup_func", and let the user decide whether to use g_slist_copy () or g_slist_copy_deep (), by manual Vala methods.

BTW: Same for GLib.List.

Thanks
Tal
Comment 1 GNOME Infrastructure Team 2018-05-22 14:36:05 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/334.