On Thu, May 23, 2024 at 06:02:25AM -0400, Jeff King wrote: > On Tue, May 21, 2024 at 03:02:29PM -0400, Taylor Blau wrote: > > > Future commits will want to parse a floating point value from > > configuration, but we have no way to parse such a value prior to this > > patch. > > > > The core of the routine is implemented in git_parse_float(). Unlike > > git_parse_unsigned() and git_parse_signed(), however, the function > > implemented here only works on type "float", and not related types like > > "double", or "long double". > > > > This is because "double" and "long double" use different functions to > > convert from ASCII strings to floating point values (strtod() and > > strtold(), respectively). Likewise, there is no pointer type that can > > assign to any of these values (except for "void *"), so the only way to > > define this trio of functions would be with a macro expansion that is > > parameterized over the floating point type and conversion function. > > I agree it doesn't make sense to support both. But if we have to choose > between the two, should we just use "double"? Yeah, I share your feeling that there is no great need to support double-precision floats here, but there's also no reason to artificially limit ourselves to single-precision ones, either. > Regarding using non-integers at all, I do wonder how much we need them. > We've usually stuck to integers in other spots, even if it means a sort > of pseudo-fixed-point (e.g., rename scores). Looking ahead, you're using > these for the power-series knobs. I guess it would be pretty confusing > to try to force integers there. I dunno. Not really an objection, but I > just wonder if it was something you considered. I had originally written the series that way, but Patrick suggested that I use floating point numbers instead ;-). Thanks, Taylor
