luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-12-28 16:36:14 +01:00
Code Issues Packages Projects Releases Wiki Activity

gstrfuncs: Clarify that g_ascii_strtoull() accepts signed numbers

Browse Source 
It’s perverse, but explicitly documented that strtoull() accepts numbers
with a leading minus sign (`-`) and explicitly casts them to signed
output.

g_ascii_strtoull() is documented to do what strtoull() does (but locale
independently), and its behaviour is correct. However, the documentation
could be a lot clearer about this unexpected behaviour.

Add a unit test for it too.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
This commit is contained in:
Philip Withnall 2018-12-04 12:51:09 +00:00
parent d4cc0b32fd
commit 8d0a163000
2 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
glib/gstrfuncs.c
View File

@ -1140,6 +1140,11 @@ g_parse_long_long (const gchar *nptr,
* changing the current locale, since that would not be
* thread-safe.
*
* Note that input with a leading minus sign (`-`) is accepted, and will return
* the negation of the parsed number, unless that would overflow a #guint64.
* Critically, this means you cannot assume that a short fixed length input will
* never result in a low return value, as the input could have a leading `-`.
*
* This function is typically used when reading configuration
* files or other non-user input that should be locale independent.
* To handle input from the user you should normally use the

1
glib/tests/strfuncs.c
View File

@ -1098,6 +1098,7 @@ test_strtoll (void)
check_uint64 ("18446744073709551616", "", 10, G_MAXUINT64, ERANGE);
check_uint64 ("20xyz", "xyz", 10, 20, 0);
check_uint64 ("-1", "", 10, G_MAXUINT64, 0);
check_uint64 ("-FF4", "", 16, -((guint64) 0xFF4), 0);
check_int64 ("0", "", 10, 0, 0);
check_int64 ("9223372036854775807", "", 10, G_MAXINT64, 0);