Re: Fix a host of strto*() bugs

On Tue, Aug 04, 2026 at 05:14:43PM +0200, Alvaro Herrera wrote:
> I'm thinking something like
> uint64 pg_strtouint64(const char *s, char **endptr, uint32 options, error_callback cb);
>
> where we parse and return the number, and in case of any failure, we
> call the error callback which can do an ereport() or pg_fatal() or
> whatever. So the caller need only set up a callback, and then all calls
> to the conversion function can be straightforward and not concern
> themselves with the platform specific errno handling.
>
> We can use the options bitmask to mediate any potential caller-specific
> needs, for example
> INTEGER_CONV_OCTAL
> INTEGER_CONV_HEX
> to override the default assumption of base 10.

I am not sure that we would need to diverge from the existing "base"
argument, passing down an option which is an equivalent of it feels
kind of confusing to me.

While looking at all the callers of strtou64() and strtoi64(), I can't
help but notice that each call has its own assumptions in terms of
endptr handling, minus the range checks they may or may not do. An
error callback may be adapted if some of the range checks are fixed,
but some of them rely on a parse state (parse_manifest.c). With all
that in mind, I am not entirely convinced that this would lead to an
overall simplification, quite the opposite actually. The new pg_()
routine could be given a context pointer that is passed down as an
argument of the error_callback, still that doesn't stick well here..
--
Michael