[RFC PATCH v2 2/4] Add eventfd option to --decode-fds

[Dmitry V. Levin]

On Sat, May 04, 2024 at 06:50:24PM +0530, Sahil wrote:
> On Friday, May 3, 2024 4:04:33 AM IST Dmitry V. Levin wrote:
[...]
> Sorry, I got a little confused with the naming of the function and that got
> me thinking in this direction.
> 
> I have another query regarding "string_to_uint_ex". There's the following
> condition in "string_to_uint_ex":
> > if (str == end || val < 0 || (unsigned long long) val > max_val 
> >     || (val == LLONG_MAX && errno == ERANGE)) {...}
> 
> Based on what I have understood this condition returns -1 when:
> 1. there are no digits in the string.
> 2. the number is negative.
> 3. ??
> 4. there's an overflow.
> 
> I haven't really understood the type casting part of the third condition.
> For values -1 through LLONG_MIN, the second condition takes care of it.
> And for 0 through LLONG_MAX, I don't think the explicit type cast would
> make much of a difference.

Since val has type "long long" and max_val has type "unsigned long long",
an explicit cast is needed to perform the comparison.  The compiler would
issue a warning in case of comparison between signed and unsigned values.

> In the case that there's an underflow (eg:, the value in the string is
> LLONG_MIN - 1), strtoll would still return LLONG_MIN and set the errno
> accordingly.
> 
> Could this function be refactored instead to use strtoull. Before calling this
> function, a simple pass of "str" could be performed to check if there's a
> "-" sign. If this is the case, the function immediately returns -1. Otherwise,
> we could apply strtoull and check for overflow. Using strtoull would increase
> the range of positive values that one can work with.

To use strtoull instead of strtoll, part of strtoll would have to be
open-coded, i.e., skipping leading whitespace and checking for "-".

By the way, could we just treat these eventfd-* values as strings?
This would simplify things a lot.


-- 
ldv