Parse string to long replacement
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.