-
Thomas Haller authored
- g_ascii_strtoll() accepts leading spaces, but it leaves the end pointer at the first space after the digit. That means, we accepted "1: 0" but not "1 :0". We should either consistently accept spaces around the digits/colon or reject it. - g_ascii_strtoll() accepts "\v" as a space (just like `man 3 isspace` comments that "\v" is a space in C and POSIX locale. For some reasons (unknown to me) g_ascii_isspace() does not treat "\v" as space. And neither does NM_ASCII_SPACES and nm_str_skip_leading_spaces(). We should be consistent about what we consider spaces and what not. It's already odd to accept '\n' as spaces here, but well, lets do it for the sake of consistency (so that it matches with our understanding of ASCII spaces, albeit not POSIX's). - don't use bogus error domains in "g_set_error (error, 1, 0, ..." That is a bug and we have NM_UTILS_ERROR exactly for error instances with unspecified domain and code. - as before, accept a trailing ":" with omitted minor number. - reject all unexpected characters. strtoll() accepts '+' / '-' and a "0x" prefix of the numbers (and leading POSIX spaces). Be strict here and only accepts NM_ASCII_SPACES, ':', and hexdigits. In particular, don't accept the "0x" prefix. This parsing would be significantly simpler to implement, if we could just strdup() the string, split the string at the colon delimiter and use _nm_utils_ascii_str_to_int64() which gets leading/trailing spaces right. But let's save the "overhead" of an additional alloc.
cc9f0716