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

[Sahil]

Hi,

On Sunday, May 5, 2024 2:00:12 AM IST Dmitry V. Levin wrote:
> 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.

Oh right. I forgot about the compiler warnings. This makes sense now.

> > 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 "-".

Right.

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

I think it will be easier to handle eventfd-count as a string.

For eventfd-id and eventfd-semaphore, using "string_to_uint_ex" shouldn't
be a problem since they are both "int". For these two cases the value can
be converted to an int in the same manner as pidfd in "parse_fdinfo_pid".

Thanks,
Sahil