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: Huong Dangminh <huo-dangminh@ys.jp.nec.com>, Jonathan Allen <jallen@americansavingslife.com>, Andrew Gierth <andrew@tao11.riddles.org.uk>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>, "Akio Iwaasa" <aki-iwaasa@vt.jp.nec.com>
Date: 2018-05-18T18:11:52Z
Lists: pgsql-bugs 
I wrote:
> BTW, after further digging I am suspicious that this means that we need
> to propagate HAVE_STRTOLL and HAVE_STRTOULL into ecpg_config.h not only
> pg_config.h.  I'm not totally sure which compiles include just the former
> not the latter.

After looking closer, ecpg only examines HAVE_STRTOLL and HAVE_STRTOULL
in ecpglib/data.c, which does include the main config file, so we should
be good on that.

> I'm going to wait and see if the buildfarm is unhappy before trying to
> change that, though.  It will help prove whether we're actually getting
> useful test coverage.

Nonetheless, all the 32-bit buildfarm critters are falling over, and
the reason is now obvious: HAVE_LONG_LONG_INT isn't getting defined
in the test code, because neither pg_config.h nor ecpg_config.h ever
get included there.

As a stopgap measure, we could stick #include <ecpg_config.h> into
just that one test file.  I notice however that there are more problems.
In particular, sqltypes.h supposes it has access to HAVE_LONG_LONG_INT_64,
which seems utterly naive.

It seems like really we need <ecpg_config.h> in sqltypes.h at least,
and if we don't want more bugs of the same ilk in future, it'd be
wise to stick it into something that's included by all ecpg-generated
code, like ecpglib.h.  I am however worried about invasion of client
namespace if we do that, so not quite sure what to do here.  Thoughts?

			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.