strtoll/strtoull emulation

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers