Re: [Vala] printf question

[Al Thomas <astavale yahoo co uk>]

  > On Tuesday, 9 October 2018, 16:16:44 BST, wolfgang mauer kabelmail de <wolfgang mauer kabelmail de> 
wrote:  > Is this a Bug?
> cellRendererText.text = ("%"+int64.FORMAT).printf((int64)obj); <<---- int64.FORMAT = "li"
> this works, but when i try this, witch is the same
> cellRendererText.text = ("%li").printf((int64)obj);
> i get thiss error 
> application.vala:192.45-192.54: error: Argument 1: Cannot convert from `int64' to `long'

I think it should be %lli. Try:

void main () {
    int64 a = 1234567890123456789LL;
    print ("%li\n".printf ((int32)a));
    print ("%lli\n".printf (a));
}

A 'long' is at least 32 bits, a 'long long' is at least 64 bits. A good summary is 
https://en.wikipedia.org/wiki/C_data_types
I think that was the conclusion I came to when I wrote that up in the Genie docs: 
https://wiki.gnome.org/Projects/Genie#Numbers

int64.FORMAT in Vala is bound to GLib's G_GINT64_FORMAT. See the Vala binding: 
https://gitlab.gnome.org/GNOME/vala/blob/master/vapi/glib-2.0.vapi#L687
The GLib documentation advises 'This is the platform dependent conversion specifier for scanningand printing 
values of type gint64'  See https://developer.gnome.org/glib/2.56/glib-Basic-Types.html#G-GINT64-FORMAT:CAPS 
To my mind that is wrong in GLib. Now there may be some platform reason for doing this, but I suggest you 
raise an issue with GLib at https://gitlab.gnome.org/GNOME/vala/issues then we can take it from there. 

Note how the use of just %li in my code example truncates the number. The Vala compiler is recognising this 
in your second example and giving an error. If you cast to int32 it should compile. The Vala compiler has not 
been set up to recognise the creation of %li using string concatenation. So it is passed through to the 
output C and the C compiler does its thing with a resulting potential loss of data. Is this a bug in the Vala 
compiler? May be, but there may also be a limit to how much checking can be coded in to the compiler. Of 
course if someone submitted a patch that made it just work then that would be a different story :) BTW to 
read the generated C code use the --ccode switch with valac.

Hope that helps,

Al