Petr Jelinek <p...@2ndquadrant.com> writes: > On 12/03/16 04:30, Tom Lane wrote: >> 1. I found two places (marked XXX in this patch) that are using strtoul() >> to parse a tuple count back out of a command tag. That won't do anymore. >> pg_stat_statements has a messy hack for the same problem (look for >> HAVE_STRTOULL), which is probably what we want to do, but not by >> copy-and-pasting #ifdef HAVE_STRTOULL into multiple places. I'd be >> inclined to provide a utility function "pg_strtouint64" or some such >> to encapsulate that. (numutils.c might be a good place for it.)
> Hmm, I thought that solution is not really portable for 64bit numbers > and only is allowed in pg_stat_statements because worst case it will cut > the number to 32bit int and misreport but won't break anything there. > For example windows IIRC need _strtoui64 for this. OK, we can use _strtoui64() on Windows. > I once wrote (well copy-pasted from BDS + some #define wrappers) > portable version of that, see the 0004 and bottom of 0003 in > http://www.postgresql.org/message-id/557d9ded.2080...@2ndquadrant.com (I > think at minimum what the 0003 does in c.h is needed). Meh. That seems like pretty substantial overkill. Given that we assume platforms have working 64-bit support these days, what's the probability that they don't have an appropriate strtoXXX function? Or on one that doesn't, that anyone will ever try to run >4G-tuple results through the relevant code paths? For the moment I'm just going to do this: uint64 pg_strtouint64(const char *str, char **endptr, int base) { #ifdef WIN32 return _strtoui64(str, endptr, base); #elif defined(HAVE_STRTOULL) && SIZEOF_LONG < 8 return strtoull(str, endptr, base); #else return strtoul(str, endptr, base); #endif } If there ever seems to be any practical value in improving it, we can do that later. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
