On Fri, 20 Nov 2020 16:04:15 +0000 Richard Fitzgerald <[email protected]> wrote:
> > But yeah, we could very much have cp - startp > max_chars. > > > > My code handles the prefix overflow, but I did it by having > __parse_integer_limit() simply give 0 if max_chars <= 0. Yeah, but if that's the intended result, then it needs to be commented as such, and the comment needs to be fixed. Right now it's: /* * Convert non-negative integer string representation in explicitly given radix * to an integer. The maximum number of characters to convert can be given. * A character limit of INT_MAX is effectively unlimited since a string that * long is unreasonable. * Return number of characters consumed maybe or-ed with overflow bit. * If overflow occurs, result integer (incorrect) is still returned. * * Don't you dare use this function. */ That comment needs to include: "If max_chars <= 0, then this returns zero.". -- Steve > > So if the field width isn't enough for the prefix/leading '-' and at > least one digit, subtracting the prefix length from the field length > will give a max_chars <= 0. And you'll get a result of 0 as in your > '%2li%9lx' test case. > > I thought this was nice because it didn't need to add code to check > for the prefix overflow - it comes inherently from the loop in > __parse_integer_limit(). But I'm willing to change > __parse_integer_limit() to take an unsigned and add explicit checks for > the prefix/'-' overflow cases.
