GitLab

string.to_long has been replaced by long.parse, however, their implementation have changed. string.to_long C name is strol whilst long.parse C name is atol and thus the latter can't parse hexadecimals/octal. From vapi:

        [Version (replacement = "long.parse")]
        [CCode (cname = "strtol")]
        public long to_long (out unowned string endptr = null, int _base = 0);

        [CCode (cname = "atol", cheader_filename = "stdlib.h")]
        public static long parse (string str);

The replacement for parsing int, int64, uint64 and double are consistent using atoi, g_ascii_strtoll, g_ascii_strtoull, g_ascii_strtod respectively so maybe this change wasn't intentional?

I'm aware that there are workarounds such as using the int64 parser - which can parse hex - with the appropriate cast. That being said, I did find this issue unwelcoming when fixing compiler warnings and blindly (to my fault) replacing string.to_long with long.parse to discover down the road that their behavior have changed.

To help keep things consistent I've created a table showing the old and replacement methods for parsing strings to numbers:

value type	old	old cname	replacement	replacement cname	Comment
short	na	na	na	na	-
ushort	na	na	na	na	-
int	to_int	atoi	int.parse / int.try_parse	atoi	-
uint	na	na	uint.parse / uint.try_parse	na	-
long	to_long	strtol	long.parse / long.try_parse	atol	use strtol
ulong	to_ulong	strtoul	ulong.parse / ulong.try_parse	g_ascii_strtoull	use strtoul
int64	to_int64	g_ascii_strtoll	int64.parse / int64.try_parse	g_ascii_strtoll
uint64	to_uint64	g_ascii_strtoull	uint64.parse / uint64.try_parse	g_ascii_strtoull
float	na	na	na	na	user strtof
double	to_double	g_ascii_strtod	double.parse / double.try_parse	g_ascii_strtod	leave as or maybe strtod to move away from Glib?

Note that some of the conversions are done using glib functions whilst others from standard C library. I dont know how vala copes with that but if it is a problem (or undesired), as a suggestion, one could use the g_ascii methods with an appropriate cast or alternative replace g_ascii with their stdlib equivalent.

Lastly, strol, stroll etc.. are called with base 0. Maybe add a function so that one could explicitly choose the base? There is already a definition for ascii_strotoll/strtoull/strtod in the vapi so one would only need to make them public.