Horton

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

Huong Dangminh <huo-dangminh@ys.jp.nec.com>

View thread View on postgr.es
From: Huong Dangminh <huo-dangminh@ys.jp.nec.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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-19T15:41:21Z
Lists: pgsql-bugs 
Hi,

Thanks for working a lot in this thread.

> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 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 agreed.
 
> > 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.

You have done it as the "hot-fix", thanks.
Also thanks for fixing the failed of "Buildfarm member dromedary".
# I also feel curious about it.

> 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?

I am also inclined to the above, by the way.

>> 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.

Thanks, I was misunderstood.


Thanks and best regards,
---
Dang Minh Huong
NEC Solution Innovators, Ltd.
http://www.nec-solutioninnovators.co.jp/en/

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.