On 2026-Jul-31, Michael Paquier wrote: > On Thu, Jul 30, 2026 at 08:55:02AM +0000, Tristan Partin wrote:
> > The first patch in the series fixes this issue. I did some analysis on > > other uses of strtoul() and friends and found a few more places where > > integers were not being correctly parsed from strings. Those are each > > attached as individual patches to ease backpatching if it is determined > > that we should. Otherwise, I suggest squashing the series. I wonder if > > we should come up with a helper macro for helping callers handle errors > > correctly? Or should we just always check this case? > > Some of it could be perhaps unified, but there is also some beauty in > letting the callers handle things on their own. strtou64() is for > example just a macro that stands on top of strtoul[l](). Maybe we should add our wrapper with more consistent error reporting behavior that hides all those platform-dependent differences and uses an error reporting mechanism that doesn't rely on errno. I think that would result in simpler and more consistent code. 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. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Nunca confiaré en un traidor. Ni siquiera si el traidor lo he creado yo" (Barón Vladimir Harkonnen)
