database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Make [U]INT64CONST safe for use in #if conditions.

Browse Source 
Instead of using a cast to force the constant to be the right width,
assume we can plaster on an L, UL, LL, or ULL suffix as appropriate.
The old approach to this is very hoary, dating from before we were
willing to require compilers to have working int64 types.

This fix makes the PG_INT64_MIN, PG_INT64_MAX, and PG_UINT64_MAX
constants safe to use in preprocessor conditions, where a cast
doesn't work.  Other symbolic constants that might be defined using
[U]INT64CONST are likewise safer than before.

Also fix the SIZE_MAX macro to be similarly safe, if we are forced
to provide a definition for that.  The test added in commit 2e70d6b5e
happens to do what we want even with the hack "(size_t) -1" definition,
but we could easily get burnt on other tests in future.

Back-patch to all supported branches, like the previous commits.

Discussion: https://postgr.es/m/15883.1504278595@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2017-09-01 15:14:18 -04:00
parent bf38702855
commit 1305186de4
5 changed files with 11 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
configure.in
View File

@ -1708,19 +1708,6 @@ fi
AC_DEFINE_UNQUOTED(PG_INT64_TYPE, $pg_int64_type,
[Define to the name of a signed 64-bit integer type.])
dnl If we need to use "long long int", figure out whether nnnLL notation works.
if test x"$HAVE_LONG_LONG_INT_64" = xyes ; then
AC_TRY_COMPILE([
#define INT64CONST(x) x##LL
long long int foo = INT64CONST(0x1234567890123456);
],
[],
[AC_DEFINE(HAVE_LL_CONSTANTS, 1, [Define to 1 if constants of type 'long long int' should have the suffix LL.])],
[])
fi
# If we found "long int" is 64 bits, assume snprintf handles it. If
# we found we need to use "long long int", better check. We cope with
# snprintfs that use %lld, %qd, or %I64d as the format. If none of these