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 660621 - Do not use GINT_TO_POINTER for GType
Do not use GINT_TO_POINTER for GType
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Code Generator: GType
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2011-10-01 10:16 UTC by Jens Georg
Modified: 2012-07-16 20:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Jens Georg 2011-10-01 10:16:22 UTC 
Currently when using Type in a e.g. HashTable, valac uses GINT_TO_POINTER to store the GType.

Out of bad experience with GUPnP and Rygel I know that the type id can exceed INT_MAX on 64bit systems. We switched to GSIZE_TO_POINTER in GUPnPResourceFactory due to that.
Comment 1 Jürg Billeter 2012-07-16 19:31:15 UTC 
commit d6bc0cc06f920a40faf778d5a622093ebf06ec05
Author: Jürg Billeter <j@bitron.ch>
Date:   Mon Jul 16 21:21:05 2012 +0200

    codegen: Fix conversion from generic pointer to long integer
    
    Fixes bug 660621.
Comment 2 Jens Georg 2012-07-16 19:59:19 UTC 
result = new CCodeCastExpression (new CCodeCastExpression (cexpr, "guintptr"), get_ccode_name (actual_type))

That's not what I meant - doesn't that still cut of type id's > INT_MAX ?
Comment 3 Jürg Billeter 2012-07-16 20:06:31 UTC 
(In reply to comment #2)
> result = new CCodeCastExpression (new CCodeCastExpression (cexpr, "guintptr"),
> get_ccode_name (actual_type))
> 
> That's not what I meant - doesn't that still cut of type id's > INT_MAX ?

gintptr and guintptr are pointer-sized integers, i.e., they are 64-bit on 64-bit systems. What situation do you have in mind where this could cause issues?
Comment 4 Jens Georg 2012-07-16 20:16:03 UTC 
ah, sorry, I somehow missed the ptr. nevermind :)