Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

configure

Blame
    • Tom Lane's avatar
      3a0f8e7d
      Make [U]INT64CONST safe for use in #if conditions. · 3a0f8e7d
      Tom Lane authored
      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 2e70d6b5
      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
      3a0f8e7d
      History
      Make [U]INT64CONST safe for use in #if conditions.
      Tom Lane authored
      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 2e70d6b5
      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
    configure 460.49 KiB