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

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
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>, Michael Meskes <meskes@postgresql.org>, Akio Iwaasa <aki-iwaasa@vt.jp.nec.com>
Date: 2018-05-20T13:38:18Z
Lists: pgsql-bugs

On 05/20/2018 12:12 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Well that seems to have crashed and burned badly. I'm just going to
>> disable ecpg checks on this animal as suggested upthread.
> Hmm ... this might be too much of a coincidence, but I can't help noticing
> that the places that are going south with -D__USE_MINGW_ANSI_STDIO are
> pretty nearly the same ones I just pointed to in
> https://www.postgresql.org/message-id/21670.1526769114@sss.pgh.pa.us
> as using "%lf".  I'd supposed that that was mostly compulsive neatnik-ism,
> but is it possible that mingw's "ansi stdio" library is actually
> sensitive to that?
>
> 			


Yeah, it sure is. With that applied ecpg-check actually passes on 
frogmouth. If you apply it to all the live branches I'll re-enable the 
tests.

cheers

andrew


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.