Thread: strtoll/strtoull emulation
Hi, I recently had the need to use strtoull() in postgres code. Only to discover that that's not available on some platforms. IIRC windows/msvc was one of them. Now 9d7ded0f4277f5c0063eca8e871a34e2355a8371 added another user - guarded by HAVE_STRTOULL. That commit will make things worse on windows btw... How about adding emulation for strtoll/strtoull to port/? The BSDs have easily crib-able functions available... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes:
> I recently had the need to use strtoull() in postgres code. Only to
> discover that that's not available on some platforms. IIRC windows/msvc
> was one of them. Now 9d7ded0f4277f5c0063eca8e871a34e2355a8371 added
> another user - guarded by HAVE_STRTOULL. That commit will make things
> worse on windows btw...
Worse than what? AFAICT, the old code would produce complete garbage
on Windows. The new code at least gives the right answer for rowcounts
up to 4GB.
> How about adding emulation for strtoll/strtoull to port/? The BSDs have
> easily crib-able functions available...
Ugh. Surely Windows has got *some* equivalent, perhaps named differently?
regards, tom lane
On 2014-06-03 10:55:17 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > I recently had the need to use strtoull() in postgres code. Only to > > discover that that's not available on some platforms. IIRC windows/msvc > > was one of them. Now 9d7ded0f4277f5c0063eca8e871a34e2355a8371 added > > another user - guarded by HAVE_STRTOULL. That commit will make things > > worse on windows btw... > > Worse than what? AFAICT, the old code would produce complete garbage > on Windows. The new code at least gives the right answer for rowcounts > up to 4GB. Hm? Wouldn't it only have produced garbage on mingw and not msvc? > > How about adding emulation for strtoll/strtoull to port/? The BSDs have > > easily crib-able functions available... > > 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@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.
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.
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().
regards, tom lane
On 2014-06-03 11:28:22 -0400, Tom Lane wrote: > Andres Freund <andres@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