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 552566 - time_t to long mapping probably incorrect
time_t to long mapping probably incorrect
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-09-16 22:42 UTC by Mike Kestner
Modified: 2015-02-07 16:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
add time_t concept to .typelib and GIR (6.29 KB, patch)
2008-09-19 02:45 UTC, Colin Walters
reviewed Details | Review

Description Mike Kestner 2008-09-16 22:42:18 UTC
Please describe the problem:
type elements map c:type="time_t" to name="long".  While size-wise, I think that's universally correct, it loses a lot of context in the mapping.  In Gtk#, we map time_t values to .Net DateTime structures.  This mapping would force us to fall back to the c:type for additional information.  

I think it would be better to just map time_t to itself, or some agreed upon namespaced name which does not dump the time-related context of the native type.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Colin Walters 2008-09-19 00:27:00 UTC
Agreed, I think we need the concept of time_t in the GIR and typelib; we have size_t which is similar.  I think there might have been another special C type or two?
Comment 2 Colin Walters 2008-09-19 02:45:57 UTC
Created attachment 118980 [details] [review]
add time_t concept to .typelib and GIR
Comment 3 Johan (not receiving bugmail) Dahlin 2008-09-23 17:58:46 UTC
Comment on attachment 118980 [details] [review]
add time_t concept to .typelib and GIR

>diff --git a/girepository/girepository.h b/girepository/girepository.h
>index 0a7bbb7..d3f6818 100644
>+  GI_TYPE_TAG_TIME_T    = 18,

End of list perhaps?
(not that we guarantee API/ABI stability yet, but at some point we will)

Maybe just call it GI_TYPE_TAG_TIME?
It would cause less confusion if decide to another time structure to 
the time_t type tag in the future.

>diff --git a/girepository/girparser.c b/girepository/girparser.c
[..]
>+    { "time_t",   GI_TYPE_TAG_TIME_T,  0 },

>diff --git a/giscanner/ast.py b/giscanner/ast.py
[..]
>+TYPE_TIMET = 'time_t'

>diff --git a/tools/generate.c b/tools/generate.c
[..]
>+    "time_t", 

"time"? (see above)

Looks good anyway, you can commit with or without addressing the comments above.
Comment 4 Colin Walters 2008-09-23 18:16:12 UTC
The reason it's not at the end of the list is various things use "< GI_TYPE_TAG_ARRAY" for "is basic".  

As for renaming to "time", I think we need a specific type for time_t because it's special in C, i.e. it's undefined whether it's an int/double/long, and so the bindings will need to handle it with compile-time knowledge.

Other time types like GLib.TimeVal would be handled on a per-binding way.
Comment 5 Colin Walters 2008-09-23 18:20:52 UTC
commit a0a98bfcd8252203bd1b603811dcd67ee13c1042
Merge: 62c7f9e... 38ad05d...
Author: walters <walters@f5b5f685-ed25-0410-8673-93f92c561f07>
Date:   Tue Sep 23 18:20:25 2008 +0000

    Merge branch 'bug552566-timet/wip'
    
    
    git-svn-id: svn+ssh://svn.gnome.org/svn/gobject-introspection/trunk@624 f5b5f685-ed25-0410-8673-93f92c561f07
Comment 6 André Klapper 2015-02-07 16:44:33 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]