Re: [HACKERS] Missing SIZE_MAX - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Missing SIZE_MAX
Date
Msg-id 26331.1504290332@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Missing SIZE_MAX  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> It might be worth the effort to clean all of this up, just because the
>> next person who gets bitten by it may not be as smart as you are.

> Yeah.  I was just thinking that maybe the appropriate investment of
> effort is to make [U]INT64CONST smarter, so that it results in a
> properly-suffixed constant and doesn't need a cast.  Then it'd be a
> lot easier to make these other macros be #if-safe.

Actually, that looks easier than I thought.  The current approach to
[U]INT64CONST dates to before we were willing to require the compiler
to have working 64-bit support.  I think that now we can just assume
that either an L/UL or LL/ULL suffix will work, as in the attached
draft.  (This'd allow dropping configure's HAVE_LL_CONSTANTS probe
entirely, but I didn't do that yet.)

            regards, tom lane

diff --git a/src/include/c.h b/src/include/c.h
index 4f8bbfc..4fb8ef0 100644
*** a/src/include/c.h
--- b/src/include/c.h
*************** typedef long int int64;
*** 288,293 ****
--- 288,295 ----
  #ifndef HAVE_UINT64
  typedef unsigned long int uint64;
  #endif
+ #define INT64CONST(x)  (x##L)
+ #define UINT64CONST(x) (x##UL)
  #elif defined(HAVE_LONG_LONG_INT_64)
  /* We have working support for "long long int", use that */

*************** typedef long long int int64;
*** 297,316 ****
  #ifndef HAVE_UINT64
  typedef unsigned long long int uint64;
  #endif
  #else
  /* neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 */
  #error must have a working 64-bit integer datatype
  #endif

- /* Decide if we need to decorate 64-bit constants */
- #ifdef HAVE_LL_CONSTANTS
- #define INT64CONST(x)  ((int64) x##LL)
- #define UINT64CONST(x) ((uint64) x##ULL)
- #else
- #define INT64CONST(x)  ((int64) x)
- #define UINT64CONST(x) ((uint64) x)
- #endif
-
  /* snprintf format strings to use for 64-bit integers */
  #define INT64_FORMAT "%" INT64_MODIFIER "d"
  #define UINT64_FORMAT "%" INT64_MODIFIER "u"
--- 299,311 ----
  #ifndef HAVE_UINT64
  typedef unsigned long long int uint64;
  #endif
+ #define INT64CONST(x)  (x##LL)
+ #define UINT64CONST(x) (x##ULL)
  #else
  /* neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 */
  #error must have a working 64-bit integer datatype
  #endif

  /* snprintf format strings to use for 64-bit integers */
  #define INT64_FORMAT "%" INT64_MODIFIER "d"
  #define UINT64_FORMAT "%" INT64_MODIFIER "u"
*************** typedef unsigned PG_INT128_TYPE uint128;
*** 338,351 ****
  #define PG_UINT16_MAX    (0xFFFF)
  #define PG_INT32_MIN    (-0x7FFFFFFF-1)
  #define PG_INT32_MAX    (0x7FFFFFFF)
! #define PG_UINT32_MAX    (0xFFFFFFFF)
  #define PG_INT64_MIN    (-INT64CONST(0x7FFFFFFFFFFFFFFF) - 1)
  #define PG_INT64_MAX    INT64CONST(0x7FFFFFFFFFFFFFFF)
  #define PG_UINT64_MAX    UINT64CONST(0xFFFFFFFFFFFFFFFF)

  /* Max value of size_t might also be missing if we don't have stdint.h */
  #ifndef SIZE_MAX
! #define SIZE_MAX ((size_t) -1)
  #endif

  /*
--- 333,350 ----
  #define PG_UINT16_MAX    (0xFFFF)
  #define PG_INT32_MIN    (-0x7FFFFFFF-1)
  #define PG_INT32_MAX    (0x7FFFFFFF)
! #define PG_UINT32_MAX    (0xFFFFFFFFU)
  #define PG_INT64_MIN    (-INT64CONST(0x7FFFFFFFFFFFFFFF) - 1)
  #define PG_INT64_MAX    INT64CONST(0x7FFFFFFFFFFFFFFF)
  #define PG_UINT64_MAX    UINT64CONST(0xFFFFFFFFFFFFFFFF)

  /* Max value of size_t might also be missing if we don't have stdint.h */
  #ifndef SIZE_MAX
! #if SIZEOF_SIZE_T == 8
! #define SIZE_MAX PG_UINT64_MAX
! #else
! #define SIZE_MAX PG_UINT32_MAX
! #endif
  #endif

  /*

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [HACKERS] GnuTLS support
Next
From: David Steele
Date:
Subject: Re: [HACKERS] Rename RECOVERYXLOG to RECOVERYWAL?