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 584517 - native type issues
native type issues
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-06-01 17:22 UTC by David Zeuthen (not reading bugmail)
Modified: 2018-02-08 11:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Zeuthen (not reading bugmail) 2009-06-01 17:22:39 UTC
So I have this typedef in one of my projects

/**
 * GUdevDeviceNumber:
 *
 * Corresponds to the standard #dev_t type as defined by POSIX.
 */
typedef dev_t GUdevDeviceNumber;

which gives me

 <alias name="DeviceNumber" target="dev_t" c:type="GUdevDeviceNumber"/>

in the GIR file.

Of course, this is not very useful for e.g. seed or gjs, they simply don't understand what dev_t is. And I'd argue they shouldn't have to know.

Wouldn't it be better if g-ir-scanner resolved 'dev_t' to 'int' at scan time?

The easy fix is to do

 typedef int GUdevDeviceNumber;

but that's not really a solution since dev_t, as specified by POSIX, can be any arithmetic type (e.g. int16_t, int32_t, whatever) and the decomposition into major:minor (and even existance of major:minor) is platform specific (e.g. can different on Linux and Solaris and why makedev(3) isn't specified by POSIX).

Maybe it's just easier to teach g-ir-scanner about such POSIX types and then alias them to the right int... there's not a lot of them (other types include pid_t etc.).

Thoughts?
Comment 1 Colin Walters 2009-06-05 15:36:04 UTC
For time_t we created an explicit type.  I'm not sure how well that scales though to all of POSIX.

We could make a POSIX.gir.
Comment 2 Johan (not receiving bugmail) Dahlin 2009-06-05 15:40:55 UTC
Could be, but how would we detect when to include the POSIX git or not?
Comment 3 David Zeuthen (not reading bugmail) 2009-06-05 15:49:58 UTC
(In reply to comment #2)
> Could be, but how would we detect when to include the POSIX git or not?
> 

Well, things like time_t is part of C so it wouldn't go into POSIX but rather stay in the introspection parser. 

Wit this, only things like GUdev-1.0 and GIO-unix-2.0 (which we don't have yet but probably want since it's not right to have GDesktopAppInfo in Gio-2.0) would pull in POSIX-1.0.
Comment 4 David Zeuthen (not reading bugmail) 2009-06-05 15:52:05 UTC
(In reply to comment #3)
> GIO-unix-2.0 (which we don't have yet
> but probably want since it's not right to have GDesktopAppInfo in Gio-2.0)

Filed as bug 584936.
Comment 5 Colin Walters 2010-03-11 15:27:12 UTC
After thinking about this a bit more, I'd rather the scanner made it convenient to pass in alias definitions, like --alias dev_t=guint64, or parse it from a file.
Or maybe even better --expand-typedef=dev_t which would make us walk through and expand to the typedef target.
Comment 6 André Klapper 2015-02-07 17:17:08 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 7 Mikhail Zabaluev 2015-10-30 23:16:00 UTC
(In reply to Colin Walters from comment #5)
> Or maybe even better --expand-typedef=dev_t which would make us walk through
> and expand to the typedef target.

That will erase the information that the introspected typedef depends on a platform-specific type definition. For bindings that don't use the installed C headers, that information would be useful; see bug #757165.
Comment 8 GNOME Infrastructure Team 2018-02-08 11:50:15 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/gobject-introspection/issues/18.