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: Huong Dangminh <huo-dangminh@ys.jp.nec.com>
Cc: Jonathan Allen <jallen@americansavingslife.com>, Michael Meskes <meskes@postgresql.org>, 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-18T17:07:56Z
Lists: pgsql-bugs 
Huong Dangminh <huo-dangminh@ys.jp.nec.com> writes:
>> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>> BTW, is it possible to set up an ecpg test case to verify that this stuff
>> works?
>> It'd have to handle platforms without long long though, so I'm not
>> sure how to deal with that.

> Yes. I was expecting that at least bigint will works fine with sqlda in linux 
> system but it seem did not?

After some thought I decided that the right fix is to add coverage for
both ECPGt_long and ECPGt_long_long.  Any given platform will test only
one of those two code paths, but that's probably fine, because that is
the only one it would use anyway.

Pushed it that way; the buildfarm will soon tell us if this was a
stupid idea ...

			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.