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 722570 - Add various functions to SHORT and USHORT types
Add various functions to SHORT and USHORT types
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Bindings: GLib
0.23.x
Other Linux
: Normal enhancement
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2014-01-19 21:48 UTC by oliver.steven
Modified: 2018-05-22 15:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to add described functions (1.92 KB, patch)
2014-01-19 21:48 UTC, oliver.steven
none Details | Review

Description oliver.steven 2014-01-19 21:48:16 UTC
Created attachment 266680 [details] [review]
Patch to add described functions

This patch should add the following functions to both the SHORT type and the USHORT type:

* to_pointer
* to_big_endian
* to_little_endian
* from_big_endian
* from_little_endian

It also removes a stray space from the header. Since I was in there I fixed it.
Comment 1 Jürg Billeter 2014-01-19 21:58:43 UTC
Review of attachment 266680 [details] [review]:

Thanks for your patch.

::: vapi/glib-2.0.vapi
@@ +207,3 @@
+
+	[CCode (cname = "GINT_TO_POINTER")]
+	public void* to_pointer ();

Do you know of a use case where this makes sense? I can't think of one right now.

@@ +217,3 @@
+	public static short from_big_endian (short val);
+	[CCode (cname = "GINT_FROM_LE")]
+	public static short from_little_endian (short val);

Does this work? Using GINT_TO/FROM* for shorts doesn't seem right to me.
Comment 2 Luca Bruno 2014-01-19 22:03:07 UTC
I don't find the .to_pointer() useful to be honest, (void*)num is enough.
Comment 3 oliver.steven 2014-01-19 23:17:54 UTC
(In reply to comment #1)
> Review of attachment 266680 [details] [review]:
> 
> Thanks for your patch.
> 
> ::: vapi/glib-2.0.vapi
> @@ +207,3 @@
> +
> +    [CCode (cname = "GINT_TO_POINTER")]
> +    public void* to_pointer ();
> 
> Do you know of a use case where this makes sense? I can't think of one right
> now.
I do not have a use case, but that's not saying much.
Comment 4 oliver.steven 2014-01-20 18:02:05 UTC
(In reply to comment #1)
> Review of attachment 266680 [details] [review]:
> @@ +217,3 @@
> +    public static short from_big_endian (short val);
> +    [CCode (cname = "GINT_FROM_LE")]
> +    public static short from_little_endian (short val);
> 
> Does this work? Using GINT_TO/FROM* for shorts doesn't seem right to me.

Why wouldn't it work? A short is 16 bits; that gives you 8 bits to swap side to side.
Comment 5 Maciej (Matthew) Piechotka 2014-01-20 21:03:39 UTC
(In reply to comment #4)
> (In reply to comment #1)
> > Review of attachment 266680 [details] [review] [details]:
> > @@ +217,3 @@
> > +    public static short from_big_endian (short val);
> > +    [CCode (cname = "GINT_FROM_LE")]
> > +    public static short from_little_endian (short val);
> > 
> > Does this work? Using GINT_TO/FROM* for shorts doesn't seem right to me.
> 
> Why wouldn't it work? A short is 16 bits; that gives you 8 bits to swap side to
> side.

Assume that you have a different ordering (you convert from LE to BE or other way round). You have XY as input (short). So byte extended to int in GINT_FROM_LE/GINT_FROM_BE it'd be BBXY (where B is -1 or 0 depending on sign). Swapped it's YXBB. However then you cast to short ignoring the ordering (processor and/or C view the type as short so it assumes native ordering) which causes it to drop 2 most significant bytes which results in value BB.

PS. short technically does not have to have a size of 16 bits.
Comment 6 GNOME Infrastructure Team 2018-05-22 15:03:50 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/428.