Horton

Re: BUG #15080: ecpg on windows doesn't define HAVE_LONG_LONG_INT

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Meskes <meskes@postgresql.org>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>, jallen@americansavingslife.com, pgsql-bugs@lists.postgresql.org
Date: 2018-02-24T20:03:14Z
Lists: pgsql-bugs 
Michael Meskes <meskes@postgresql.org> writes:
>> Solution.pm has this:
>> ...
>> from which HAVE_LONG_LONG_INT seems to be suspiciously missing?

> Right, but it is missing in pg_config.h, too, right?

No, it does get defined on Unix builds (if appropriate), both in
pg_config.h and ecpg_config.h.  As far as I can see in a quick
grep, the core code doesn't use that symbol anywhere anyway ...
but ecpg does.  It's the fact that ecpg_config.h gets the
symbol defined on Unix builds but not MSVC builds that Andrew
is on about.

			regards, tom lane

Commits

  1. Remove configure's check for nonstandard "long long" printf modifiers.

  2. printf("%lf") is not portable, so omit the "l".

  3. Support platforms where strtoll/strtoull are spelled __strtoll/__strtoull.

  4. Arrange to supply declarations for strtoll/strtoull if needed.

  5. Hot-fix ecpg regression test for missing ecpg_config.h inclusion.

  6. Add some test coverage for ecpg's "long long" support.

  7. Recognize that MSVC can support strtoll() and strtoull().

  8. Fix up ecpg's configuration so it handles "long long int" in MSVC builds.