lkml.org 
[lkml]   [2012]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Lib:The patch include fix for "-" during string to long conversion
Namit Gupta <namit2010@gmail.com> wrote:
> API simple_strtol() and simple_strtoul() are giving incorrect result for
> string "-".
> These API's consider "-" as a '-' (negative integer) and return incorrect
> string pointer.
> The API returns pointer next to '-' character. However it should return
> starting pointer of the string.
> Below I have included possible solution for that issue.
> Please review.

tl;dr: Interesting issue. Arguably, but not toally clear that, this is
a bug. However, the proposed fix is broken; better fix below.


Just to clarify, the issue is that when fed the string "-", simple_strtol
is setting endp to cp+1 (and returning 0). I don't think there's actually
anything wrong with simple_strtoul; did you mean simple_strtoull()?

glibc's strtol, for example, returns 0 digits converted when fed strings
that consist of a valid prefix (whitespace plus optional sign) if not
followed by valid digits. (I just checked.)

If you want to follow C89 exactly (even though, by not permitting leading
whitespace or + signs, simple_strtol() obviously *doesn't*), returning
*endp = cp is required. The question is what simple_strtol *should* do.

C89 talks about breaking the input into leading whitespace, a "subject
sequence" of characters beginning with the first non-whitespace, and a
final string of unrecognized characters.

Then C89 defines the "expected form" of the subject sequence as "that
of an integer constant as described in §3.1.3.2, optionally preceded by
a plus or minus sign, but not including an integer suffix." The grammar
in the given section does not permit 0-length strings.

(The above is if base=0; if base != 0, the validity of 0-length
strings is not clear.)

Finally, we get to:
# If the subject sequence is empty or does not have the expected
# form, no conversion is performed; the value of nptr is stored in the
# object pointed to by endptr, provided that endptr is not a null
# pointer.

Thus, since "-" is not of the expected form, *endp = cp is required.


The question is whether a "simple_" variant should be expected to do
lookahead like this, or if it should just do what the strtol man page
says: "strtol() stores the address of the first invalid character in
*endptr."

An important point is that lookahead already exists in the handling of
"0x" prefixes. "0x0" through "0xf" are valid hex numbers, but "0xg"
and the like are 1-digit numbers followed by an unparsed string.
(See _parse_integer_fixup_radix() in lib/kstrtox.c.)


Independent of the above discussion, the proposed fix is definitely
not okay. If you're going to consider this a bug, fix it properly
and also return 0 for "-z" as well; don't special-case the NUL byte.

It's awkward to do by pre-validating cp[1], because the range of valid
digits depends on the base. A simpler fix would let simple_strotul make
that determination:

long simple_strtol(const char *cp, char **endp, unsigned int base)
{
long l;

if (cp[0] != '-')
return simple_strtoul(cp, endp, base);
l = -simple_strtoul(cp+1, endp, base);
/* Return 0 digits converted if - sign is followed by 0 valid digits */
if (endp && *endp == cp+1)
*endp = cp;
return l;
}

(Signed-off-by: George Spelvin <linux@horizon.com> if anyone wants to
copy this logic to simple_strtoll and turn it into a proper patch.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-11-05 00:01    [W:0.029 / U:0.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site