GScanner, strtol() and int64

[Tim Janik <timj gtk org>]

GScanner currently has a pretty annoying bug. any integer bigger
than 2147483647 (2^31-1) is parsed and returned as 2147483647.
eventhough for 32 bit integers, GScanner is capable of returning
values up to 4294967295 (2^32-1) due to v_int being unsigned
long in GTokenValue:

union _GTokenValue
{
  [...]
  gulong        v_int;
  gdouble       v_float;
  [...]
};

this is due to GScanner using strtol() internally to convert
strings to integers.

another annoyance of GScanner is that it doesn't support
scanning of 64bit integers, but could binary compatibly be
extended to do so:

union _GTokenValue
{
  [...]
  gulong        v_int;
+ guint64       v_int64; /* sizeof (guint64) == sizeof (double) */
  gdouble       v_float;
  [...]
};

struct  _GScannerConfig
{
  [...]
  guint         scope_0_fallback : 1;           /* try scope 0 on lookups? */
+ guint         numbers_2_int64 : 1;   /* currently default initialized with 0 */
  guint         padding_dummy;
};


this leaves the question of how to convert strings to integers
>2147483647.
strtoul(3) would fix the first problem outlined
for 32 bit integers, and according to its man page conforms
to SVID 3, BSD 4.3, ISO 9899 (C99) and POSIX, so is hopefully
reasonably portable.
strtoull(3) on the other hand, required for 64bit integers, is
mentioned to conform only to ISO 9899 (C99) and POSIX-2001.

ideally, i'd like to switch this over to strtoull(3), but it
looks like that's not portable enough. sscanf() wouldn't work
btw (besides possible portability problems pending there as
well), because GScanner needs to parse integers in bases 2,
8, 10 and 16.

considering that GScanner doesn't need to deal with locale
specific numbering oddities (it doesn't parse those characters
as part of a number in the first place), it might be best to
roll a strtoull(3) implementation in gscanner.c for just the 4
bases needed.

however, there's also the possibility of implementing
g_ascii_strtoull() which we might want to have anyway for
C-locale alike atoi behaviour and portable 64bit integer
parsing.

it's not clear to me what the best solution would be,
so i'd like to hear people's opinions on this.

---
ciaoTJ