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-18T15:07:52Z
Lists: pgsql-bugs 
Huong Dangminh <huo-dangminh@ys.jp.nec.com> writes:
>> Attached test patch works fine in Windows, but in Linux system the
>> sqlda->sqlvar[i].sqltype return ECPGt_long but not ECPGt_long_long (as
>> expected) when reference to bigint column.
>> Is this another problem in linux? Or am I wrong something?

That would depend on what platform you're running on: if it's 64-bit
then "long int" is probably 64 bits wide, making that a perfectly valid
answer.

AIUI, the idea in ecpg is to support "long long int" program variables
if the compiler has such a type, without any particular assumptions about
how wide that type is.  But whether the SQL type int8 maps to long or
long long is going to be platform-specific, which evidently is another
hurdle to testing anything here :-(

			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.