On 6/21/17 3:29 PM, Darrick J. Wong wrote:
> On Wed, Jun 21, 2017 at 03:16:37PM -0500, Eric Sandeen wrote:
...
>>> --- a/libxcmd/input.c
>>> +++ b/libxcmd/input.c
>>> @@ -149,6 +149,140 @@ numlen(
>>> return len == 0 ? 1 : len;
>>> }
>>>
>>> +/*
>>> + * Convert string to int64_t, set errno if the conversion fails or
>>> + * doesn't fit. Does not allow unit specifiers. Sets errno to zero
>>> + * prior to conversion.
>>> + */
>>> +int64_t
>>> +cvt_s64(
>>> + char *s,
>>> + int base)
>>> +{
>>> + long long i;
>>> + char *sp;
>>> + int c;
>>
>> unused var c
>>
>>> +
>>> + errno = 0;
>>> + i = strtoll(s, &sp, base);
>>> + if (*sp == '\0' && sp != s)
>>> + return i;
>>> +bad:
>>
>> label bad: defined but not used
>
> Fixed. Sorry about the stupidity. :(
no problem, things like this make me feel better :D
>
>>> + errno = -ERANGE;
>>> + return INT64_MIN;
>>
>> Hm, doesn't strtoll return LLONG_MIN or LLONG_MAX for underflows
>> and overflows? Do you really want to return MIN even if this /overflowed/?
>> (Maybe it doesn't matter, gut its a bit of a departure from strtoll semantics)
>
> True, it's a departure from the usual semantics. The intent is to call
> the function this way:
>
> long foo = cvt_s64(...);
> if (errno) {
> fprintf(stderr, "N|_|MB3Rz ARE HARDZ!!1!\n");
> exit(5);
> }
>
> So at least in theory it wouldn't matter what we actually set foo to.
well, that was my next question. ;)
But setting it to one extreme value leaves me wondering why you'd not set it
to the other extreme. *shrug* Not that big a deal, just a thing that made me
go "hmmmm"
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
