On 2014-06-03 11:28:22 -0400, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-06-03 10:55:17 -0400, Tom Lane wrote: > >> Ugh. Surely Windows has got *some* equivalent, perhaps named differently? > > > Apparently they've added strtoull()/stroll() to msvc 2013... And there's > > _strtoui64() which seems to have already existed a while back. > > > But it seems easier to me to add one fallback centrally somewhere that > > works on all platforms. I am not sure that msvc is the only platform > > missing strtoull() - although I didn't find anything relevant in a quick > > search through the buildfarm. So maybe I am worrying over nothing. > > It used to be called strtouq on some really old platforms, but we already > have code to deal with that naming.
So I guess we can just add a similar #define for _strto[u]i64 somewhere in port/. And then fail if strtoull isn't available. > I checked my pet dinosaur HPUX box, and it has HAVE_LONG_LONG_INT64 but > not HAVE_STRTOULL. It's very possibly the last such animal in captivity > though. I'm not really sure it's worth carrying a port file just to keep > that platform alive. I don't dare to make a judgement on that ;) > Another issue is that strtoull() is not necessarily what we want anyway: > what we want is the function corresponding to uint64, which on most > modern platforms is going to be strtoul(). How about adding pg_strto[u]int(32|64) to deal with that? Mabye without the pg_ prefix? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
