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 679351 - Correct annotation for g_mkdtemp
Correct annotation for g_mkdtemp
Status: RESOLVED WONTFIX
Product: glib
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-07-03 21:08 UTC by Jasper St. Pierre (not reading bugmail)
Modified: 2012-07-06 23:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Correct annotation for g_mkdtemp (1.30 KB, patch)
2012-07-03 21:08 UTC, Jasper St. Pierre (not reading bugmail)
needs-work Details | Review

Description Jasper St. Pierre (not reading bugmail) 2012-07-03 21:08:38 UTC
See patch. This may seem a bit strange, but it is true that the function consumes the argument we give it (transfer full), and doesn't free the pointer that it returns back to us (transfer full). PyGObject needs a patch to handle in arguments with (transfer full) correctly, I have a local patch.
Comment 1 Jasper St. Pierre (not reading bugmail) 2012-07-03 21:08:40 UTC
Created attachment 217966 [details] [review]
Correct annotation for g_mkdtemp
Comment 2 Matthias Clasen 2012-07-04 01:20:04 UTC
It does not consume the argument. It returns the a pointer to the same string, which has been modified in place.
Comment 3 Matthias Clasen 2012-07-06 01:20:50 UTC
Review of attachment 217966 [details] [review]:

.
Comment 4 Matthias Clasen 2012-07-06 01:21:02 UTC
Review of attachment 217966 [details] [review]:

.
Comment 5 Colin Walters 2012-07-06 14:49:28 UTC
The introspection (transfer) semantics could be interpreted in two different ways:

1) Ownership of the type (refcount, malloc/free)
2) For container types, whether or not the contents are mutated

And we've pretty much settled on (transfer) describing 1).  It's completely silent on 2).  Having it mean *both* would be problematic.

So basically, thinking of a char * as a container of bytes, this API is not introspectable.  We could add a new API that took a GString * (with no transfer, because we're not taking ownership of the refcount), but I think a better fix would be an API in GIO for this that returned a newly-allocated GFile *.
Comment 6 Giovanni Campagna 2012-07-06 23:21:16 UTC
Instead of considering the ideal concept of ownership, let's look at the reality of bindings, and how they interpret these annotations.

In all bindings with managed memory, strings are allocated by the language runtime. Therefore there is no way to implement (transfer full) without a copy before invoking the method.
Which means that annotating (transfer full), to the external observer, is equivalent to creating a wrapper C function that is (transfer none) and copies its argument before calling the real one.

That is, (transfer full) is safe to use for annotating function that don't copy but change their argument, since they'll always operate on a copy.

Doing it with annotations then has the advantage that it doesn't clutter the C API needlessly, and requires no extra code or tests.
Also, in gjs (and possibly pygobject with python3), a copy is always required to convert from Unicode to utf8, so (transfer full) saves from another one.
Comment 7 Jasper St. Pierre (not reading bugmail) 2012-07-06 23:21:51 UTC
apparently there is a g_dir_make_tmp.

why do we bother wrapping the garbage c stdlib when we have a good api in place
Comment 8 Jasper St. Pierre (not reading bugmail) 2012-07-06 23:23:30 UTC
(In reply to comment #6)
> Instead of considering the ideal concept of ownership, let's look at the
> reality of bindings, and how they interpret these annotations.

Let's not, thanks.