postgresql/src/include/c.h

1270 lines
39 KiB
C
Raw Normal View History

1996-10-31 08:10:14 +01:00
/*-------------------------------------------------------------------------
*
* c.h
* Fundamental C definitions. This is included by every .c file in
* PostgreSQL (via either postgres.h or postgres_fe.h, as appropriate).
*
* Note that the definitions here are not intended to be exposed to clients
* of the frontend interface libraries --- so we don't worry much about
* polluting the namespace with lots of stuff...
1996-10-31 08:10:14 +01:00
*
*
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
1996-10-31 08:10:14 +01:00
*
2010-09-20 22:08:53 +02:00
* src/include/c.h
1996-10-31 08:10:14 +01:00
*
*-------------------------------------------------------------------------
*/
/*
*----------------------------------------------------------------
* TABLE OF CONTENTS
1996-10-31 08:10:14 +01:00
*
* When adding stuff to this file, please try to put stuff
* into the relevant section, or add new sections as appropriate.
1996-10-31 08:10:14 +01:00
*
* section description
* ------- ------------------------------------------------
* 0) pg_config.h and standard system headers
* 1) compiler characteristics
* 2) bool, true, false
* 3) standard system types
* 4) IsValid macros for system types
* 5) offsetof, lengthof, alignment
* 6) assertions
* 7) widely useful macros
* 8) random stuff
* 9) system-specific hacks
1996-10-31 08:10:14 +01:00
*
* NOTE: since this file is included by both frontend and backend modules,
* it's usually wrong to put an "extern" declaration here, unless it's
* ifdef'd so that it's seen in only one case or the other.
* typedefs and macros are the kind of thing that might go here.
*
*----------------------------------------------------------------
1996-10-31 08:10:14 +01:00
*/
#ifndef C_H
1996-10-31 08:10:14 +01:00
#define C_H
#include "postgres_ext.h"
/* Must undef pg_config_ext.h symbols before including pg_config.h */
#undef PG_INT64_TYPE
1999-07-17 06:12:10 +02:00
#include "pg_config.h"
#include "pg_config_manual.h" /* must be after pg_config.h */
#include "pg_config_os.h" /* must be before any system header files */
/* System header files that should be available everywhere in Postgres */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stddef.h>
#include <stdarg.h>
#ifdef HAVE_STRINGS_H
#include <strings.h>
#endif
#ifdef HAVE_STDINT_H
#include <stdint.h>
#endif
2002-08-21 19:20:58 +02:00
#include <sys/types.h>
1999-01-17 07:20:06 +01:00
#include <errno.h>
2004-09-09 02:59:49 +02:00
#if defined(WIN32) || defined(__CYGWIN__)
2003-08-04 02:43:34 +02:00
#include <fcntl.h> /* ensure O_BINARY is available */
#endif
#include <locale.h>
#ifdef ENABLE_NLS
#include <libintl.h>
#endif
1999-01-17 07:20:06 +01:00
/* ----------------------------------------------------------------
* Section 1: compiler characteristics
*
* type prefixes (const, signed, volatile, inline) are handled in pg_config.h.
* ----------------------------------------------------------------
*/
/*
* Disable "inline" if PG_FORCE_DISABLE_INLINE is defined.
* This is used to work around compiler bugs and might also be useful for
* investigatory purposes.
*/
#ifdef PG_FORCE_DISABLE_INLINE
#undef inline
#define inline
#endif
/*
* Attribute macros
*
* GCC: https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
* GCC: https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html
* Sunpro: https://docs.oracle.com/cd/E18659_01/html/821-1384/gjzke.html
* XLC: http://www-01.ibm.com/support/knowledgecenter/SSGH2K_11.1.0/com.ibm.xlc111.aix.doc/language_ref/function_attributes.html
* XLC: http://www-01.ibm.com/support/knowledgecenter/SSGH2K_11.1.0/com.ibm.xlc111.aix.doc/language_ref/type_attrib.html
*/
/* only GCC supports the unused attribute */
#ifdef __GNUC__
#define pg_attribute_unused() __attribute__((unused))
#else
#define pg_attribute_unused()
#endif
/*
* Append PG_USED_FOR_ASSERTS_ONLY to definitions of variables that are only
* used in assert-enabled builds, to avoid compiler warnings about unused
* variables in assert-disabled builds.
*/
#ifdef USE_ASSERT_CHECKING
#define PG_USED_FOR_ASSERTS_ONLY
#else
#define PG_USED_FOR_ASSERTS_ONLY pg_attribute_unused()
#endif
2005-02-15 02:03:47 +01:00
/* GCC and XLC support format attributes */
#if defined(__GNUC__) || defined(__IBMC__)
#define pg_attribute_format_arg(a) __attribute__((format_arg(a)))
#define pg_attribute_printf(f,a) __attribute__((format(PG_PRINTF_ATTRIBUTE, f, a)))
#else
#define pg_attribute_format_arg(a)
#define pg_attribute_printf(f,a)
#endif
/* GCC, Sunpro and XLC support aligned, packed and noreturn */
#if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_attribute_aligned(a) __attribute__((aligned(a)))
#define pg_attribute_noreturn() __attribute__((noreturn))
#define pg_attribute_packed() __attribute__((packed))
#define HAVE_PG_ATTRIBUTE_NORETURN 1
#else
2005-02-15 02:03:47 +01:00
/*
* NB: aligned and packed are not given default definitions because they
* affect code functionality; they *must* be implemented by the compiler
* if they are to be used.
2005-02-15 02:03:47 +01:00
*/
#define pg_attribute_noreturn()
#endif
/*
* Use "pg_attribute_always_inline" in place of "inline" for functions that
* we wish to force inlining of, even when the compiler's heuristics would
* choose not to. But, if possible, don't force inlining in unoptimized
* debug builds.
*/
#if (defined(__GNUC__) && __GNUC__ > 3 && defined(__OPTIMIZE__)) || defined(__SUNPRO_C) || defined(__IBMC__)
/* GCC > 3, Sunpro and XLC support always_inline via __attribute__ */
#define pg_attribute_always_inline __attribute__((always_inline)) inline
#elif defined(_MSC_VER)
/* MSVC has a special keyword for this */
#define pg_attribute_always_inline __forceinline
#else
/* Otherwise, the best we can do is to say "inline" */
#define pg_attribute_always_inline inline
#endif
/*
* Forcing a function not to be inlined can be useful if it's the slow path of
* a performance-critical function, or should be visible in profiles to allow
* for proper cost attribution. Note that unlike the pg_attribute_XXX macros
* above, this should be placed before the function's return type and name.
*/
/* GCC, Sunpro and XLC support noinline via __attribute__ */
#if (defined(__GNUC__) && __GNUC__ > 2) || defined(__SUNPRO_C) || defined(__IBMC__)
#define pg_noinline __attribute__((noinline))
/* msvc via declspec */
#elif defined(_MSC_VER)
#define pg_noinline __declspec(noinline)
#else
#define pg_noinline
#endif
1996-10-31 08:10:14 +01:00
/*
* Mark a point as unreachable in a portable fashion. This should preferably
* be something that the compiler understands, to aid code generation.
* In assert-enabled builds, we prefer abort() for debugging reasons.
*/
#if defined(HAVE__BUILTIN_UNREACHABLE) && !defined(USE_ASSERT_CHECKING)
#define pg_unreachable() __builtin_unreachable()
#elif defined(_MSC_VER) && !defined(USE_ASSERT_CHECKING)
#define pg_unreachable() __assume(0)
#else
#define pg_unreachable() abort()
#endif
/*
* Hints to the compiler about the likelihood of a branch. Both likely() and
* unlikely() return the boolean value of the contained expression.
1996-10-31 08:10:14 +01:00
*
* These should only be used sparingly, in very hot code paths. It's very easy
* to mis-estimate likelihoods.
1996-10-31 08:10:14 +01:00
*/
#if __GNUC__ >= 3
#define likely(x) __builtin_expect((x) != 0, 1)
#define unlikely(x) __builtin_expect((x) != 0, 0)
#else
#define likely(x) ((x) != 0)
#define unlikely(x) ((x) != 0)
#endif
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* CppAsString
* Convert the argument to a string, using the C preprocessor.
* CppAsString2
* Convert the argument to a string, after one round of macro expansion.
1999-05-25 18:15:34 +02:00
* CppConcat
* Concatenate two arguments together, using the C preprocessor.
*
* Note: There used to be support here for pre-ANSI C compilers that didn't
* support # and ##. Nowadays, these macros are just for clarity and/or
* backward compatibility with existing PostgreSQL code.
1996-10-31 08:10:14 +01:00
*/
#define CppAsString(identifier) #identifier
#define CppAsString2(x) CppAsString(x)
#define CppConcat(x, y) x##y
/*
* VA_ARGS_NARGS
* Returns the number of macro arguments it is passed.
*
* An empty argument still counts as an argument, so effectively, this is
* "one more than the number of commas in the argument list".
*
* This works for up to 63 arguments. Internally, VA_ARGS_NARGS_() is passed
* 64+N arguments, and the C99 standard only requires macros to allow up to
* 127 arguments, so we can't portably go higher. The implementation is
* pretty trivial: VA_ARGS_NARGS_() returns its 64th argument, and we set up
* the call so that that is the appropriate one of the list of constants.
* This idea is due to Laurent Deniau.
*/
#define VA_ARGS_NARGS(...) \
VA_ARGS_NARGS_(__VA_ARGS__, \
63,62,61,60, \
59,58,57,56,55,54,53,52,51,50, \
49,48,47,46,45,44,43,42,41,40, \
39,38,37,36,35,34,33,32,31,30, \
29,28,27,26,25,24,23,22,21,20, \
19,18,17,16,15,14,13,12,11,10, \
9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
#define VA_ARGS_NARGS_( \
_01,_02,_03,_04,_05,_06,_07,_08,_09,_10, \
_11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \
_21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \
_31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \
_41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \
_51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \
_61,_62,_63, N, ...) \
(N)
/*
* dummyret is used to set return values in macros that use ?: to make
* assignments. gcc wants these to be void, other compilers like char
*/
1999-05-25 18:15:34 +02:00
#ifdef __GNUC__ /* GNU cc */
#define dummyret void
#else
#define dummyret char
1996-10-31 08:10:14 +01:00
#endif
/* Which __func__ symbol do we have, if any? */
#ifdef HAVE_FUNCNAME__FUNC
#define PG_FUNCNAME_MACRO __func__
#else
#ifdef HAVE_FUNCNAME__FUNCTION
#define PG_FUNCNAME_MACRO __FUNCTION__
#else
#define PG_FUNCNAME_MACRO NULL
#endif
#endif
/* ----------------------------------------------------------------
* Section 2: bool, true, false
* ----------------------------------------------------------------
*/
/*
* bool
* Boolean value, either true or false.
*
* Use stdbool.h if available and its bool has size 1. That's useful for
* better compiler and debugger output and for compatibility with third-party
* libraries. But PostgreSQL currently cannot deal with bool of other sizes;
* there are static assertions around the code to prevent that.
*
* For C++ compilers, we assume the compiler has a compatible built-in
* definition of bool.
*/
#ifndef __cplusplus
#if defined(HAVE_STDBOOL_H) && SIZEOF_BOOL == 1
#include <stdbool.h>
#define USE_STDBOOL 1
#else
#ifndef bool
typedef unsigned char bool;
#endif
#ifndef true
#define true ((bool) 1)
#endif
#ifndef false
#define false ((bool) 0)
#endif
#endif
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* not C++ */
1996-10-31 08:10:14 +01:00
/* ----------------------------------------------------------------
* Section 3: standard system types
1996-10-31 08:10:14 +01:00
* ----------------------------------------------------------------
*/
/*
1999-05-25 18:15:34 +02:00
* Pointer
* Variable holding address of any memory resident object.
*
* XXX Pointer arithmetic is done with this, so it can't be void *
* under "true" ANSI compilers.
*/
typedef char *Pointer;
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* intN
* Signed integer, EXACTLY N BITS IN SIZE,
* used for numerical computations and the
* frontend/backend protocol.
1996-10-31 08:10:14 +01:00
*/
#ifndef HAVE_INT8
typedef signed char int8; /* == 8 bits */
typedef signed short int16; /* == 16 bits */
typedef signed int int32; /* == 32 bits */
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* not HAVE_INT8 */
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* uintN
* Unsigned integer, EXACTLY N BITS IN SIZE,
* used for numerical computations and the
* frontend/backend protocol.
1996-10-31 08:10:14 +01:00
*/
#ifndef HAVE_UINT8
typedef unsigned char uint8; /* == 8 bits */
typedef unsigned short uint16; /* == 16 bits */
typedef unsigned int uint32; /* == 32 bits */
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* not HAVE_UINT8 */
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* bitsN
* Unit of bitwise operation, AT LEAST N BITS IN SIZE.
1996-10-31 08:10:14 +01:00
*/
typedef uint8 bits8; /* >= 8 bits */
typedef uint16 bits16; /* >= 16 bits */
typedef uint32 bits32; /* >= 32 bits */
1996-10-31 08:10:14 +01:00
/*
* 64-bit integers
*/
#ifdef HAVE_LONG_INT_64
/* Plain "long int" fits, use it */
#ifndef HAVE_INT64
typedef long int int64;
#endif
#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 */
#ifndef HAVE_INT64
typedef long long int int64;
#endif
#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
2001-03-22 05:01:46 +01:00
/* snprintf format strings to use for 64-bit integers */
#define INT64_FORMAT "%" INT64_MODIFIER "d"
#define UINT64_FORMAT "%" INT64_MODIFIER "u"
/*
* 128-bit signed and unsigned integers
Prevent int128 from requiring more than MAXALIGN alignment. Our initial work with int128 neglected alignment considerations, an oversight that came back to bite us in bug #14897 from Vincent Lachenal. It is unsurprising that int128 might have a 16-byte alignment requirement; what's slightly more surprising is that even notoriously lax Intel chips sometimes enforce that. Raising MAXALIGN seems out of the question: the costs in wasted disk and memory space would be significant, and there would also be an on-disk compatibility break. Nor does it seem very practical to try to allow some data structures to have more-than-MAXALIGN alignment requirement, as we'd have to push knowledge of that throughout various code that copies data structures around. The only way out of the box is to make type int128 conform to the system's alignment assumptions. Fortunately, gcc supports that via its __attribute__(aligned()) pragma; and since we don't currently support int128 on non-gcc-workalike compilers, we shouldn't be losing any platform support this way. Although we could have just done pg_attribute_aligned(MAXIMUM_ALIGNOF) and called it a day, I did a little bit of extra work to make the code more portable than that: it will also support int128 on compilers without __attribute__(aligned()), if the native alignment of their 128-bit-int type is no more than that of int64. Add a regression test case that exercises the one known instance of the problem, in parallel aggregation over a bigint column. This will need to be back-patched, along with the preparatory commit 91aec93e6. But let's see what the buildfarm makes of it first. Discussion: https://postgr.es/m/20171110185747.31519.28038@wrigleys.postgresql.org
2017-11-14 21:03:55 +01:00
* There currently is only limited support for such types.
* E.g. 128bit literals and snprintf are not supported; but math is.
* Also, because we exclude such types when choosing MAXIMUM_ALIGNOF,
* it must be possible to coerce the compiler to allocate them on no
* more than MAXALIGN boundaries.
*/
#if defined(PG_INT128_TYPE)
Prevent int128 from requiring more than MAXALIGN alignment. Our initial work with int128 neglected alignment considerations, an oversight that came back to bite us in bug #14897 from Vincent Lachenal. It is unsurprising that int128 might have a 16-byte alignment requirement; what's slightly more surprising is that even notoriously lax Intel chips sometimes enforce that. Raising MAXALIGN seems out of the question: the costs in wasted disk and memory space would be significant, and there would also be an on-disk compatibility break. Nor does it seem very practical to try to allow some data structures to have more-than-MAXALIGN alignment requirement, as we'd have to push knowledge of that throughout various code that copies data structures around. The only way out of the box is to make type int128 conform to the system's alignment assumptions. Fortunately, gcc supports that via its __attribute__(aligned()) pragma; and since we don't currently support int128 on non-gcc-workalike compilers, we shouldn't be losing any platform support this way. Although we could have just done pg_attribute_aligned(MAXIMUM_ALIGNOF) and called it a day, I did a little bit of extra work to make the code more portable than that: it will also support int128 on compilers without __attribute__(aligned()), if the native alignment of their 128-bit-int type is no more than that of int64. Add a regression test case that exercises the one known instance of the problem, in parallel aggregation over a bigint column. This will need to be back-patched, along with the preparatory commit 91aec93e6. But let's see what the buildfarm makes of it first. Discussion: https://postgr.es/m/20171110185747.31519.28038@wrigleys.postgresql.org
2017-11-14 21:03:55 +01:00
#if defined(pg_attribute_aligned) || ALIGNOF_PG_INT128_TYPE <= MAXIMUM_ALIGNOF
#define HAVE_INT128 1
typedef PG_INT128_TYPE int128
#if defined(pg_attribute_aligned)
pg_attribute_aligned(MAXIMUM_ALIGNOF)
#endif
;
typedef unsigned PG_INT128_TYPE uint128
#if defined(pg_attribute_aligned)
pg_attribute_aligned(MAXIMUM_ALIGNOF)
#endif
;
#endif
#endif
/*
* stdint.h limits aren't guaranteed to be present and aren't guaranteed to
* have compatible types with our fixed width types. So just define our own.
*/
#define PG_INT8_MIN (-0x7F-1)
#define PG_INT8_MAX (0x7F)
#define PG_UINT8_MAX (0xFF)
#define PG_INT16_MIN (-0x7FFF-1)
#define PG_INT16_MAX (0x7FFF)
#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
/*
* We now always use int64 timestamps, but keep this symbol defined for the
* benefit of external code that might test it.
*/
#define HAVE_INT64_TIMESTAMP
1996-10-31 08:10:14 +01:00
/*
* Size
* Size of any memory resident object, as returned by sizeof.
1996-10-31 08:10:14 +01:00
*/
typedef size_t Size;
/*
* Index
* Index into any memory resident array.
*
* Note:
* Indices are non negative.
*/
typedef unsigned int Index;
/*
* Offset
* Offset into any memory resident array.
*
* Note:
* This differs from an Index in that an Index is always
* non negative, whereas Offset may be negative.
*/
typedef signed int Offset;
/*
* Common Postgres datatype names (as used in the catalogs)
*/
typedef float float4;
typedef double float8;
/*
* Oid, RegProcedure, TransactionId, SubTransactionId, MultiXactId,
* CommandId
*/
/* typedef Oid is in postgres_ext.h */
/*
* regproc is the type name used in the include/catalog headers, but
* RegProcedure is the preferred name in C code.
*/
typedef Oid regproc;
typedef regproc RegProcedure;
typedef uint32 TransactionId;
typedef uint32 LocalTransactionId;
typedef uint32 SubTransactionId;
#define InvalidSubTransactionId ((SubTransactionId) 0)
#define TopSubTransactionId ((SubTransactionId) 1)
/* MultiXactId must be equivalent to TransactionId, to fit in t_xmax */
typedef TransactionId MultiXactId;
typedef uint32 MultiXactOffset;
typedef uint32 CommandId;
1996-10-31 08:10:14 +01:00
#define FirstCommandId ((CommandId) 0)
#define InvalidCommandId (~(CommandId)0)
1996-10-31 08:10:14 +01:00
/*
* Array indexing support
1996-10-31 08:10:14 +01:00
*/
#define MAXDIM 6
typedef struct
{
int indx[MAXDIM];
2017-06-21 20:39:04 +02:00
} IntArray;
1996-10-31 08:10:14 +01:00
/* ----------------
* Variable-length datatypes all share the 'struct varlena' header.
*
* NOTE: for TOASTable types, this is an oversimplification, since the value
* may be compressed or moved out-of-line. However datatype-specific routines
* are mostly content to deal with de-TOASTed values only, and of course
* client-side routines should never see a TOASTed value. But even in a
* de-TOASTed value, beware of touching vl_len_ directly, as its
* representation is no longer convenient. It's recommended that code always
* use macros VARDATA_ANY, VARSIZE_ANY, VARSIZE_ANY_EXHDR, VARDATA, VARSIZE,
* and SET_VARSIZE instead of relying on direct mentions of the struct fields.
* See postgres.h for details of the TOASTed form.
* ----------------
1996-10-31 08:10:14 +01:00
*/
struct varlena
{
char vl_len_[4]; /* Do not touch this field directly! */
char vl_dat[FLEXIBLE_ARRAY_MEMBER]; /* Data content is here */
};
1996-10-31 08:10:14 +01:00
#define VARHDRSZ ((int32) sizeof(int32))
1996-10-31 08:10:14 +01:00
/*
* These widely-used datatypes are just a varlena header and the data bytes.
* There is no terminating null or anything like that --- the data length is
* always VARSIZE_ANY_EXHDR(ptr).
1996-10-31 08:10:14 +01:00
*/
typedef struct varlena bytea;
typedef struct varlena text;
typedef struct varlena BpChar; /* blank-padded char, ie SQL char(n) */
2001-03-22 05:01:46 +01:00
typedef struct varlena VarChar; /* var-length char, ie SQL varchar(n) */
1996-10-31 08:10:14 +01:00
/*
* Specialized array types. These are physically laid out just the same
* as regular arrays (so that the regular array subscripting code works
* with them). They exist as distinct types mostly for historical reasons:
* they have nonstandard I/O behavior which we don't want to change for fear
* of breaking applications that look at the system catalogs. There is also
* an implementation issue for oidvector: it's part of the primary key for
* pg_proc, and we can't use the normal btree array support routines for that
* without circularity.
1996-10-31 08:10:14 +01:00
*/
typedef struct
{
int32 vl_len_; /* these fields must match ArrayType! */
int ndim; /* always 1 for int2vector */
int32 dataoffset; /* always 0 for int2vector */
Oid elemtype;
int dim1;
int lbound1;
int16 values[FLEXIBLE_ARRAY_MEMBER];
} int2vector;
1996-10-31 08:10:14 +01:00
typedef struct
{
int32 vl_len_; /* these fields must match ArrayType! */
int ndim; /* always 1 for oidvector */
int32 dataoffset; /* always 0 for oidvector */
Oid elemtype;
int dim1;
int lbound1;
Oid values[FLEXIBLE_ARRAY_MEMBER];
} oidvector;
1996-10-31 08:10:14 +01:00
/*
Reduce the alignment requirement of type "name" from int to char, and arrange to suppress zero-padding of "name" entries in indexes. The alignment change is unlikely to save any space, but it is really needed anyway to make the world safe for our widespread practice of passing plain old C strings to functions that are declared as taking Name. In the previous coding, the C compiler was entitled to assume that a Name pointer was word-aligned; but we were failing to guarantee that. I think the reason we'd not seen failures is that usually the only thing that gets done with such a pointer is strcmp(), which is hard to optimize in a way that exploits word-alignment. Still, some enterprising compiler guy will probably think of a way eventually, or we might change our code in a way that exposes more-obvious optimization opportunities. The padding change is accomplished in one-liner fashion by declaring the "name" index opclasses to use storage type "cstring" in pg_opclass.h. Normally btree and hash don't allow a nondefault storage type, because they don't have any provisions for converting the input datum to another type. However, because name and cstring are effectively the same thing except for padding, no conversion is needed --- we only need index_form_tuple() to treat the datum as being cstring not name, and this is sufficient. This seems to make for about a one-third reduction in the typical sizes of system catalog indexes that involve "name" columns, of which we have many. These two changes are only weakly related, but the alignment change makes me feel safer that the padding change won't introduce problems, so I'm committing them together.
2008-06-24 19:58:27 +02:00
* Representation of a Name: effectively just a C string, but null-padded to
* exactly NAMEDATALEN bytes. The use of a struct is historical.
*/
Reduce the alignment requirement of type "name" from int to char, and arrange to suppress zero-padding of "name" entries in indexes. The alignment change is unlikely to save any space, but it is really needed anyway to make the world safe for our widespread practice of passing plain old C strings to functions that are declared as taking Name. In the previous coding, the C compiler was entitled to assume that a Name pointer was word-aligned; but we were failing to guarantee that. I think the reason we'd not seen failures is that usually the only thing that gets done with such a pointer is strcmp(), which is hard to optimize in a way that exploits word-alignment. Still, some enterprising compiler guy will probably think of a way eventually, or we might change our code in a way that exposes more-obvious optimization opportunities. The padding change is accomplished in one-liner fashion by declaring the "name" index opclasses to use storage type "cstring" in pg_opclass.h. Normally btree and hash don't allow a nondefault storage type, because they don't have any provisions for converting the input datum to another type. However, because name and cstring are effectively the same thing except for padding, no conversion is needed --- we only need index_form_tuple() to treat the datum as being cstring not name, and this is sufficient. This seems to make for about a one-third reduction in the typical sizes of system catalog indexes that involve "name" columns, of which we have many. These two changes are only weakly related, but the alignment change makes me feel safer that the padding change won't introduce problems, so I'm committing them together.
2008-06-24 19:58:27 +02:00
typedef struct nameData
{
char data[NAMEDATALEN];
} NameData;
typedef NameData *Name;
#define NameStr(name) ((name).data)
1996-10-31 08:10:14 +01:00
/* ----------------------------------------------------------------
* Section 4: IsValid macros for system types
1996-10-31 08:10:14 +01:00
* ----------------------------------------------------------------
*/
/*
1999-05-25 18:15:34 +02:00
* BoolIsValid
* True iff bool is valid.
1996-10-31 08:10:14 +01:00
*/
#define BoolIsValid(boolean) ((boolean) == false || (boolean) == true)
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* PointerIsValid
* True iff pointer is valid.
1996-10-31 08:10:14 +01:00
*/
#define PointerIsValid(pointer) ((const void*)(pointer) != NULL)
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* PointerIsAligned
* True iff pointer is properly aligned to point to the given type.
1996-10-31 08:10:14 +01:00
*/
#define PointerIsAligned(pointer, type) \
(((uintptr_t)(pointer) % (sizeof (type))) == 0)
1996-10-31 08:10:14 +01:00
#define OffsetToPointer(base, offset) \
((void *)((char *) base + offset))
#define OidIsValid(objectId) ((bool) ((objectId) != InvalidOid))
#define RegProcedureIsValid(p) OidIsValid(p)
1996-10-31 08:10:14 +01:00
/* ----------------------------------------------------------------
* Section 5: offsetof, lengthof, alignment
1996-10-31 08:10:14 +01:00
* ----------------------------------------------------------------
*/
/*
1999-05-25 18:15:34 +02:00
* offsetof
* Offset of a structure/union field within that structure/union.
1996-10-31 08:10:14 +01:00
*
* XXX This is supposed to be part of stddef.h, but isn't on
* some systems (like SunOS 4).
1996-10-31 08:10:14 +01:00
*/
#ifndef offsetof
#define offsetof(type, field) ((long) &((type *)0)->field)
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* offsetof */
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* lengthof
* Number of elements in an array.
1996-10-31 08:10:14 +01:00
*/
#define lengthof(array) (sizeof (array) / sizeof ((array)[0]))
1996-10-31 08:10:14 +01:00
/* ----------------
* Alignment macros: align a length or address appropriately for a given type.
* The fooALIGN() macros round up to a multiple of the required alignment,
* while the fooALIGN_DOWN() macros round down. The latter are more useful
* for problems like "how many X-sized structures will fit in a page?".
1996-10-31 08:10:14 +01:00
*
* NOTE: TYPEALIGN[_DOWN] will not work if ALIGNVAL is not a power of 2.
* That case seems extremely unlikely to be needed in practice, however.
*
* NOTE: MAXIMUM_ALIGNOF, and hence MAXALIGN(), intentionally exclude any
* larger-than-8-byte types the compiler might have.
* ----------------
1996-10-31 08:10:14 +01:00
*/
#define TYPEALIGN(ALIGNVAL,LEN) \
(((uintptr_t) (LEN) + ((ALIGNVAL) - 1)) & ~((uintptr_t) ((ALIGNVAL) - 1)))
1996-10-31 08:10:14 +01:00
#define SHORTALIGN(LEN) TYPEALIGN(ALIGNOF_SHORT, (LEN))
#define INTALIGN(LEN) TYPEALIGN(ALIGNOF_INT, (LEN))
#define LONGALIGN(LEN) TYPEALIGN(ALIGNOF_LONG, (LEN))
#define DOUBLEALIGN(LEN) TYPEALIGN(ALIGNOF_DOUBLE, (LEN))
#define MAXALIGN(LEN) TYPEALIGN(MAXIMUM_ALIGNOF, (LEN))
/* MAXALIGN covers only built-in types, not buffers */
#define BUFFERALIGN(LEN) TYPEALIGN(ALIGNOF_BUFFER, (LEN))
#define CACHELINEALIGN(LEN) TYPEALIGN(PG_CACHE_LINE_SIZE, (LEN))
1996-10-31 08:10:14 +01:00
#define TYPEALIGN_DOWN(ALIGNVAL,LEN) \
(((uintptr_t) (LEN)) & ~((uintptr_t) ((ALIGNVAL) - 1)))
#define SHORTALIGN_DOWN(LEN) TYPEALIGN_DOWN(ALIGNOF_SHORT, (LEN))
#define INTALIGN_DOWN(LEN) TYPEALIGN_DOWN(ALIGNOF_INT, (LEN))
#define LONGALIGN_DOWN(LEN) TYPEALIGN_DOWN(ALIGNOF_LONG, (LEN))
#define DOUBLEALIGN_DOWN(LEN) TYPEALIGN_DOWN(ALIGNOF_DOUBLE, (LEN))
#define MAXALIGN_DOWN(LEN) TYPEALIGN_DOWN(MAXIMUM_ALIGNOF, (LEN))
#define BUFFERALIGN_DOWN(LEN) TYPEALIGN_DOWN(ALIGNOF_BUFFER, (LEN))
1996-10-31 08:10:14 +01:00
/*
* The above macros will not work with types wider than uintptr_t, like with
* uint64 on 32-bit platforms. That's not problem for the usual use where a
* pointer or a length is aligned, but for the odd case that you need to
* align something (potentially) wider, use TYPEALIGN64.
*/
#define TYPEALIGN64(ALIGNVAL,LEN) \
(((uint64) (LEN) + ((ALIGNVAL) - 1)) & ~((uint64) ((ALIGNVAL) - 1)))
/* we don't currently need wider versions of the other ALIGN macros */
#define MAXALIGN64(LEN) TYPEALIGN64(MAXIMUM_ALIGNOF, (LEN))
1996-10-31 08:10:14 +01:00
/* ----------------------------------------------------------------
* Section 6: assertions
* ----------------------------------------------------------------
*/
/*
* USE_ASSERT_CHECKING, if defined, turns on all the assertions.
* - plai 9/5/90
*
* It should _NOT_ be defined in releases or in benchmark copies
*/
/*
* Assert() can be used in both frontend and backend code. In frontend code it
* just calls the standard assert, if it's available. If use of assertions is
* not configured, it does nothing.
*/
#ifndef USE_ASSERT_CHECKING
#define Assert(condition) ((void)true)
#define AssertMacro(condition) ((void)true)
#define AssertArg(condition) ((void)true)
#define AssertState(condition) ((void)true)
Add a basic atomic ops API abstracting away platform/architecture details. Several upcoming performance/scalability improvements require atomic operations. This new API avoids the need to splatter compiler and architecture dependent code over all the locations employing atomic ops. For several of the potential usages it'd be problematic to maintain both, a atomics using implementation and one using spinlocks or similar. In all likelihood one of the implementations would not get tested regularly under concurrency. To avoid that scenario the new API provides a automatic fallback of atomic operations to spinlocks. All properties of atomic operations are maintained. This fallback - obviously - isn't as fast as just using atomic ops, but it's not bad either. For one of the future users the atomics ontop spinlocks implementation was actually slightly faster than the old purely spinlock using implementation. That's important because it reduces the fear of regressing older platforms when improving the scalability for new ones. The API, loosely modeled after the C11 atomics support, currently provides 'atomic flags' and 32 bit unsigned integers. If the platform efficiently supports atomic 64 bit unsigned integers those are also provided. To implement atomics support for a platform/architecture/compiler for a type of atomics 32bit compare and exchange needs to be implemented. If available and more efficient native support for flags, 32 bit atomic addition, and corresponding 64 bit operations may also be provided. Additional useful atomic operations are implemented generically ontop of these. The implementation for various versions of gcc, msvc and sun studio have been tested. Additional existing stub implementations for * Intel icc * HUPX acc * IBM xlc are included but have never been tested. These will likely require fixes based on buildfarm and user feedback. As atomic operations also require barriers for some operations the existing barrier support has been moved into the atomics code. Author: Andres Freund with contributions from Oskari Saarenmaa Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com, 20131015123303.GH5300@awork2.anarazel.de, 20131028205522.GI20248@awork2.anarazel.de
2014-09-25 23:49:05 +02:00
#define AssertPointerAlignment(ptr, bndr) ((void)true)
#define Trap(condition, errorType) ((void)true)
#define TrapMacro(condition, errorType) (true)
#elif defined(FRONTEND)
#include <assert.h>
#define Assert(p) assert(p)
#define AssertMacro(p) ((void) assert(p))
#define AssertArg(condition) assert(condition)
#define AssertState(condition) assert(condition)
Add a basic atomic ops API abstracting away platform/architecture details. Several upcoming performance/scalability improvements require atomic operations. This new API avoids the need to splatter compiler and architecture dependent code over all the locations employing atomic ops. For several of the potential usages it'd be problematic to maintain both, a atomics using implementation and one using spinlocks or similar. In all likelihood one of the implementations would not get tested regularly under concurrency. To avoid that scenario the new API provides a automatic fallback of atomic operations to spinlocks. All properties of atomic operations are maintained. This fallback - obviously - isn't as fast as just using atomic ops, but it's not bad either. For one of the future users the atomics ontop spinlocks implementation was actually slightly faster than the old purely spinlock using implementation. That's important because it reduces the fear of regressing older platforms when improving the scalability for new ones. The API, loosely modeled after the C11 atomics support, currently provides 'atomic flags' and 32 bit unsigned integers. If the platform efficiently supports atomic 64 bit unsigned integers those are also provided. To implement atomics support for a platform/architecture/compiler for a type of atomics 32bit compare and exchange needs to be implemented. If available and more efficient native support for flags, 32 bit atomic addition, and corresponding 64 bit operations may also be provided. Additional useful atomic operations are implemented generically ontop of these. The implementation for various versions of gcc, msvc and sun studio have been tested. Additional existing stub implementations for * Intel icc * HUPX acc * IBM xlc are included but have never been tested. These will likely require fixes based on buildfarm and user feedback. As atomic operations also require barriers for some operations the existing barrier support has been moved into the atomics code. Author: Andres Freund with contributions from Oskari Saarenmaa Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com, 20131015123303.GH5300@awork2.anarazel.de, 20131028205522.GI20248@awork2.anarazel.de
2014-09-25 23:49:05 +02:00
#define AssertPointerAlignment(ptr, bndr) ((void)true)
#else /* USE_ASSERT_CHECKING && !FRONTEND */
/*
* Trap
* Generates an exception if the given condition is true.
*/
#define Trap(condition, errorType) \
do { \
if (condition) \
ExceptionalCondition(CppAsString(condition), (errorType), \
__FILE__, __LINE__); \
} while (0)
/*
* TrapMacro is the same as Trap but it's intended for use in macros:
*
* #define foo(x) (AssertMacro(x != 0), bar(x))
*
* Isn't CPP fun?
*/
#define TrapMacro(condition, errorType) \
((bool) (! (condition) || \
(ExceptionalCondition(CppAsString(condition), (errorType), \
__FILE__, __LINE__), 0)))
#define Assert(condition) \
Trap(!(condition), "FailedAssertion")
#define AssertMacro(condition) \
((void) TrapMacro(!(condition), "FailedAssertion"))
#define AssertArg(condition) \
Trap(!(condition), "BadArgument")
#define AssertState(condition) \
Trap(!(condition), "BadState")
Add a basic atomic ops API abstracting away platform/architecture details. Several upcoming performance/scalability improvements require atomic operations. This new API avoids the need to splatter compiler and architecture dependent code over all the locations employing atomic ops. For several of the potential usages it'd be problematic to maintain both, a atomics using implementation and one using spinlocks or similar. In all likelihood one of the implementations would not get tested regularly under concurrency. To avoid that scenario the new API provides a automatic fallback of atomic operations to spinlocks. All properties of atomic operations are maintained. This fallback - obviously - isn't as fast as just using atomic ops, but it's not bad either. For one of the future users the atomics ontop spinlocks implementation was actually slightly faster than the old purely spinlock using implementation. That's important because it reduces the fear of regressing older platforms when improving the scalability for new ones. The API, loosely modeled after the C11 atomics support, currently provides 'atomic flags' and 32 bit unsigned integers. If the platform efficiently supports atomic 64 bit unsigned integers those are also provided. To implement atomics support for a platform/architecture/compiler for a type of atomics 32bit compare and exchange needs to be implemented. If available and more efficient native support for flags, 32 bit atomic addition, and corresponding 64 bit operations may also be provided. Additional useful atomic operations are implemented generically ontop of these. The implementation for various versions of gcc, msvc and sun studio have been tested. Additional existing stub implementations for * Intel icc * HUPX acc * IBM xlc are included but have never been tested. These will likely require fixes based on buildfarm and user feedback. As atomic operations also require barriers for some operations the existing barrier support has been moved into the atomics code. Author: Andres Freund with contributions from Oskari Saarenmaa Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com, 20131015123303.GH5300@awork2.anarazel.de, 20131028205522.GI20248@awork2.anarazel.de
2014-09-25 23:49:05 +02:00
/*
* Check that `ptr' is `bndr' aligned.
*/
#define AssertPointerAlignment(ptr, bndr) \
Trap(TYPEALIGN(bndr, (uintptr_t)(ptr)) != (uintptr_t)(ptr), \
"UnalignedPointer")
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* USE_ASSERT_CHECKING && !FRONTEND */
/*
* ExceptionalCondition is compiled into the backend whether or not
* USE_ASSERT_CHECKING is defined, so as to support use of extensions
* that are built with that #define with a backend that isn't. Hence,
* we should declare it as long as !FRONTEND.
*/
#ifndef FRONTEND
extern void ExceptionalCondition(const char *conditionName,
const char *errorType,
const char *fileName, int lineNumber) pg_attribute_noreturn();
#endif
/*
* Macros to support compile-time assertion checks.
*
* If the "condition" (a compile-time-constant expression) evaluates to false,
* throw a compile error using the "errmessage" (a string literal).
*
* gcc 4.6 and up supports _Static_assert(), but there are bizarre syntactic
* placement restrictions. These macros make it safe to use as a statement
* or in an expression, respectively.
*
* Otherwise we fall back on a kluge that assumes the compiler will complain
* about a negative width for a struct bit-field. This will not include a
* helpful error message, but it beats not getting an error at all.
*/
#ifndef __cplusplus
#ifdef HAVE__STATIC_ASSERT
#define StaticAssertStmt(condition, errmessage) \
do { _Static_assert(condition, errmessage); } while(0)
#define StaticAssertExpr(condition, errmessage) \
((void) ({ StaticAssertStmt(condition, errmessage); true; }))
#else /* !HAVE__STATIC_ASSERT */
#define StaticAssertStmt(condition, errmessage) \
((void) sizeof(struct { int static_assert_failure : (condition) ? 1 : -1; }))
#define StaticAssertExpr(condition, errmessage) \
StaticAssertStmt(condition, errmessage)
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* HAVE__STATIC_ASSERT */
#else /* C++ */
#if defined(__cpp_static_assert) && __cpp_static_assert >= 200410
#define StaticAssertStmt(condition, errmessage) \
static_assert(condition, errmessage)
#define StaticAssertExpr(condition, errmessage) \
({ static_assert(condition, errmessage); })
#else
#define StaticAssertStmt(condition, errmessage) \
do { struct static_assert_struct { int static_assert_failure : (condition) ? 1 : -1; }; } while(0)
#define StaticAssertExpr(condition, errmessage) \
((void) ({ StaticAssertStmt(condition, errmessage); }))
#endif
#endif /* C++ */
/*
* Compile-time checks that a variable (or expression) has the specified type.
*
* AssertVariableIsOfType() can be used as a statement.
* AssertVariableIsOfTypeMacro() is intended for use in macros, eg
* #define foo(x) (AssertVariableIsOfTypeMacro(x, int), bar(x))
*
* If we don't have __builtin_types_compatible_p, we can still assert that
* the types have the same size. This is far from ideal (especially on 32-bit
* platforms) but it provides at least some coverage.
*/
#ifdef HAVE__BUILTIN_TYPES_COMPATIBLE_P
#define AssertVariableIsOfType(varname, typename) \
StaticAssertStmt(__builtin_types_compatible_p(__typeof__(varname), typename), \
CppAsString(varname) " does not have type " CppAsString(typename))
#define AssertVariableIsOfTypeMacro(varname, typename) \
(StaticAssertExpr(__builtin_types_compatible_p(__typeof__(varname), typename), \
CppAsString(varname) " does not have type " CppAsString(typename)))
#else /* !HAVE__BUILTIN_TYPES_COMPATIBLE_P */
#define AssertVariableIsOfType(varname, typename) \
StaticAssertStmt(sizeof(varname) == sizeof(typename), \
CppAsString(varname) " does not have type " CppAsString(typename))
#define AssertVariableIsOfTypeMacro(varname, typename) \
(StaticAssertExpr(sizeof(varname) == sizeof(typename), \
CppAsString(varname) " does not have type " CppAsString(typename)))
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* HAVE__BUILTIN_TYPES_COMPATIBLE_P */
/* ----------------------------------------------------------------
* Section 7: widely useful macros
1996-10-31 08:10:14 +01:00
* ----------------------------------------------------------------
*/
/*
1999-05-25 18:15:34 +02:00
* Max
* Return the maximum of two numbers.
1996-10-31 08:10:14 +01:00
*/
#define Max(x, y) ((x) > (y) ? (x) : (y))
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* Min
* Return the minimum of two numbers.
1996-10-31 08:10:14 +01:00
*/
#define Min(x, y) ((x) < (y) ? (x) : (y))
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* Abs
* Return the absolute value of the argument.
1996-10-31 08:10:14 +01:00
*/
#define Abs(x) ((x) >= 0 ? (x) : -(x))
1996-10-31 08:10:14 +01:00
/*
1999-05-25 18:15:34 +02:00
* StrNCpy
* Like standard library function strncpy(), except that result string
* is guaranteed to be null-terminated --- that is, at most N-1 bytes
* of the source string will be kept.
* Also, the macro returns no result (too hard to do that without
* evaluating the arguments multiple times, which seems worse).
*
* BTW: when you need to copy a non-null-terminated string (like a text
* datum) and add a null, do not do it with StrNCpy(..., len+1). That
* might seem to work, but it fetches one byte more than there is in the
* text object. One fine day you'll have a SIGSEGV because there isn't
* another byte before the end of memory. Don't laugh, we've had real
* live bug reports from real live users over exactly this mistake.
* Do it honestly with "memcpy(dst,src,len); dst[len] = '\0';", instead.
*/
#define StrNCpy(dst,src,len) \
do \
{ \
char * _dst = (dst); \
Size _len = (len); \
\
if (_len > 0) \
{ \
strncpy(_dst, (src), _len); \
_dst[_len-1] = '\0'; \
} \
} while (0)
/* Get a bit mask of the bits set in non-long aligned addresses */
#define LONG_ALIGN_MASK (sizeof(long) - 1)
1998-02-11 22:38:08 +01:00
1998-02-11 22:45:40 +01:00
/*
* MemSet
* Exactly the same as standard library function memset(), but considerably
* faster for zeroing small word-aligned structures (such as parsetree nodes).
* This has to be a macro because the main point is to avoid function-call
* overhead. However, we have also found that the loop is faster than
2002-10-09 01:12:22 +02:00
* native libc memset() on some platforms, even those with assembler
* memset() functions. More research needs to be done, perhaps with
* MEMSET_LOOP_LIMIT tests in configure.
*/
#define MemSet(start, val, len) \
do \
{ \
2005-07-21 17:16:30 +02:00
/* must be void* because we don't know if it is integer aligned yet */ \
void *_vstart = (void *) (start); \
int _val = (val); \
Size _len = (len); \
\
if ((((uintptr_t) _vstart) & LONG_ALIGN_MASK) == 0 && \
(_len & LONG_ALIGN_MASK) == 0 && \
_val == 0 && \
_len <= MEMSET_LOOP_LIMIT && \
/* \
* If MEMSET_LOOP_LIMIT == 0, optimizer should find \
* the whole "if" false at compile time. \
*/ \
MEMSET_LOOP_LIMIT != 0) \
{ \
long *_start = (long *) _vstart; \
long *_stop = (long *) ((char *) _start + _len); \
while (_start < _stop) \
*_start++ = 0; \
} \
else \
memset(_vstart, _val, _len); \
} while (0)
/*
* MemSetAligned is the same as MemSet except it omits the test to see if
* "start" is word-aligned. This is okay to use if the caller knows a-priori
* that the pointer is suitably aligned (typically, because he just got it
* from palloc(), which always delivers a max-aligned pointer).
*/
#define MemSetAligned(start, val, len) \
do \
{ \
long *_start = (long *) (start); \
int _val = (val); \
Size _len = (len); \
\
if ((_len & LONG_ALIGN_MASK) == 0 && \
_val == 0 && \
_len <= MEMSET_LOOP_LIMIT && \
MEMSET_LOOP_LIMIT != 0) \
{ \
long *_stop = (long *) ((char *) _start + _len); \
while (_start < _stop) \
*_start++ = 0; \
} \
else \
memset(_start, _val, _len); \
} while (0)
/*
* MemSetTest/MemSetLoop are a variant version that allow all the tests in
* MemSet to be done at compile time in cases where "val" and "len" are
* constants *and* we know the "start" pointer must be word-aligned.
* If MemSetTest succeeds, then it is okay to use MemSetLoop, otherwise use
* MemSetAligned. Beware of multiple evaluations of the arguments when using
* this approach.
*/
#define MemSetTest(val, len) \
( ((len) & LONG_ALIGN_MASK) == 0 && \
(len) <= MEMSET_LOOP_LIMIT && \
MEMSET_LOOP_LIMIT != 0 && \
(val) == 0 )
#define MemSetLoop(start, val, len) \
do \
{ \
long * _start = (long *) (start); \
long * _stop = (long *) ((char *) _start + (Size) (len)); \
\
while (_start < _stop) \
*_start++ = 0; \
} while (0)
1997-09-18 16:21:02 +02:00
1996-10-31 08:10:14 +01:00
/* ----------------------------------------------------------------
* Section 8: random stuff
1996-10-31 08:10:14 +01:00
* ----------------------------------------------------------------
*/
/*
* Invert the sign of a qsort-style comparison result, ie, exchange negative
* and positive integer values, being careful not to get the wrong answer
* for INT_MIN. The argument should be an integral variable.
*/
#define INVERT_COMPARE_RESULT(var) \
((var) = ((var) < 0) ? 1 : -(var))
/*
* Use this, not "char buf[BLCKSZ]", to declare a field or local variable
* holding a page buffer, if that page might be accessed as a page and not
* just a string of bytes. Otherwise the variable might be under-aligned,
* causing problems on alignment-picky hardware. (In some places, we use
* this to declare buffers even though we only pass them to read() and
* write(), because copying to/from aligned buffers is usually faster than
* using unaligned buffers.) We include both "double" and "int64" in the
* union to ensure that the compiler knows the value must be MAXALIGN'ed
* (cf. configure's computation of MAXIMUM_ALIGNOF).
*/
typedef union PGAlignedBlock
{
char data[BLCKSZ];
double force_align_d;
int64 force_align_i64;
} PGAlignedBlock;
/* Same, but for an XLOG_BLCKSZ-sized buffer */
typedef union PGAlignedXLogBlock
{
char data[XLOG_BLCKSZ];
double force_align_d;
int64 force_align_i64;
} PGAlignedXLogBlock;
/* msb for char */
#define HIGHBIT (0x80)
#define IS_HIGHBIT_SET(ch) ((unsigned char)(ch) & HIGHBIT)
1996-10-31 08:10:14 +01:00
/*
* Support macros for escaping strings. escape_backslash should be true
* if generating a non-standard-conforming string. Prefixing a string
* with ESCAPE_STRING_SYNTAX guarantees it is non-standard-conforming.
* Beware of multiple evaluation of the "ch" argument!
*/
#define SQL_STR_DOUBLE(ch, escape_backslash) \
((ch) == '\'' || ((ch) == '\\' && (escape_backslash)))
#define ESCAPE_STRING_SYNTAX 'E'
#define STATUS_OK (0)
#define STATUS_ERROR (-1)
#define STATUS_EOF (-2)
#define STATUS_FOUND (1)
#define STATUS_WAITING (2)
1996-10-31 08:10:14 +01:00
/*
* gettext support
*/
#ifndef ENABLE_NLS
/* stuff we'd otherwise get from <libintl.h> */
#define gettext(x) (x)
#define dgettext(d,x) (x)
#define ngettext(s,p,n) ((n) == 1 ? (s) : (p))
#define dngettext(d,s,p,n) ((n) == 1 ? (s) : (p))
#endif
#define _(x) gettext(x)
/*
* Use this to mark string constants as needing translation at some later
* time, rather than immediately. This is useful for cases where you need
* access to the original string and translated string, and for cases where
* immediate translation is not possible, like when initializing global
* variables.
* http://www.gnu.org/software/autoconf/manual/gettext/Special-cases.html
*/
#define gettext_noop(x) (x)
/*
* To better support parallel installations of major PostgreSQL
* versions as well as parallel installations of major library soname
* versions, we mangle the gettext domain name by appending those
* version numbers. The coding rule ought to be that wherever the
* domain name is mentioned as a literal, it must be wrapped into
* PG_TEXTDOMAIN(). The macros below do not work on non-literals; but
* that is somewhat intentional because it avoids having to worry
* about multiple states of premangling and postmangling as the values
* are being passed around.
*
* Make sure this matches the installation rules in nls-global.mk.
*/
#ifdef SO_MAJOR_VERSION
#define PG_TEXTDOMAIN(domain) (domain CppAsString2(SO_MAJOR_VERSION) "-" PG_MAJORVERSION)
#else
#define PG_TEXTDOMAIN(domain) (domain "-" PG_MAJORVERSION)
#endif
/*
* Macro that allows to cast constness and volatile away from an expression, but doesn't
* allow changing the underlying type. Enforcement of the latter
* currently only works for gcc like compilers.
*
* Please note IT IS NOT SAFE to cast constness away if the result will ever
* be modified (it would be undefined behaviour). Doing so anyway can cause
* compiler misoptimizations or runtime crashes (modifying readonly memory).
* It is only safe to use when the the result will not be modified, but API
* design or language restrictions prevent you from declaring that
* (e.g. because a function returns both const and non-const variables).
*
* Note that this only works in function scope, not for global variables (it'd
* be nice, but not trivial, to improve that).
*/
#if defined(HAVE__BUILTIN_TYPES_COMPATIBLE_P)
#define unconstify(underlying_type, expr) \
(StaticAssertExpr(__builtin_types_compatible_p(__typeof(expr), const underlying_type), \
"wrong cast"), \
(underlying_type) (expr))
#define unvolatize(underlying_type, expr) \
(StaticAssertExpr(__builtin_types_compatible_p(__typeof(expr), volatile underlying_type), \
"wrong cast"), \
(underlying_type) (expr))
#else
#define unconstify(underlying_type, expr) \
((underlying_type) (expr))
#define unvolatize(underlying_type, expr) \
((underlying_type) (expr))
#endif
1996-10-31 08:10:14 +01:00
/* ----------------------------------------------------------------
* Section 9: system-specific hacks
1996-10-31 08:10:14 +01:00
*
* This should be limited to things that absolutely have to be
* included in every source file. The port-specific header file
* is usually a better place for this sort of thing.
1996-10-31 08:10:14 +01:00
* ----------------------------------------------------------------
*/
/*
* NOTE: this is also used for opening text files.
2004-08-29 07:07:03 +02:00
* WIN32 treats Control-Z as EOF in files opened in text mode.
* Therefore, we open files in binary mode on Win32 so we can read
* literal control-Z. The other affect is that we see CRLF, but
2004-08-29 07:07:03 +02:00
* that is OK because we can already handle those cleanly.
*/
2004-09-09 02:59:49 +02:00
#if defined(WIN32) || defined(__CYGWIN__)
2000-06-02 18:40:09 +02:00
#define PG_BINARY O_BINARY
#define PG_BINARY_A "ab"
2001-03-22 05:01:46 +01:00
#define PG_BINARY_R "rb"
#define PG_BINARY_W "wb"
#else
2001-03-22 05:01:46 +01:00
#define PG_BINARY 0
#define PG_BINARY_A "a"
2001-03-22 05:01:46 +01:00
#define PG_BINARY_R "r"
#define PG_BINARY_W "w"
#endif
/*
* Provide prototypes for routines not present in a particular machine's
* standard C library.
*/
#if defined(HAVE_FDATASYNC) && !HAVE_DECL_FDATASYNC
extern int fdatasync(int fildes);
#endif
#ifdef HAVE_LONG_LONG_INT
/* Older platforms may provide strto[u]ll functionality under other names */
#if !defined(HAVE_STRTOLL) && defined(HAVE___STRTOLL)
#define strtoll __strtoll
#define HAVE_STRTOLL 1
#endif
#if !defined(HAVE_STRTOLL) && defined(HAVE_STRTOQ)
#define strtoll strtoq
#define HAVE_STRTOLL 1
#endif
#if !defined(HAVE_STRTOULL) && defined(HAVE___STRTOULL)
#define strtoull __strtoull
#define HAVE_STRTOULL 1
#endif
#if !defined(HAVE_STRTOULL) && defined(HAVE_STRTOUQ)
#define strtoull strtouq
#define HAVE_STRTOULL 1
#endif
#if defined(HAVE_STRTOLL) && !HAVE_DECL_STRTOLL
extern long long strtoll(const char *str, char **endptr, int base);
#endif
#if defined(HAVE_STRTOULL) && !HAVE_DECL_STRTOULL
extern unsigned long long strtoull(const char *str, char **endptr, int base);
#endif
#endif /* HAVE_LONG_LONG_INT */
#if !defined(HAVE_MEMMOVE) && !defined(memmove)
#define memmove(d, s, c) bcopy(s, d, c)
#endif
/* no special DLL markers on most ports */
#ifndef PGDLLIMPORT
#define PGDLLIMPORT
#endif
#ifndef PGDLLEXPORT
#define PGDLLEXPORT
#endif
/*
* The following is used as the arg list for signal handlers. Any ports
* that take something other than an int argument should override this in
* their pg_config_os.h file. Note that variable names are required
* because it is used in both the prototypes as well as the definitions.
* Note also the long name. We expect that this won't collide with
* other names causing compiler warnings.
2003-08-04 02:43:34 +02:00
*/
#ifndef SIGNAL_ARGS
#define SIGNAL_ARGS int postgres_signal_arg
#endif
/*
* When there is no sigsetjmp, its functionality is provided by plain
* setjmp. Incidentally, nothing provides setjmp's functionality in
* that case. We now support the case only on Windows.
*/
#ifdef WIN32
2003-08-04 02:43:34 +02:00
#define sigjmp_buf jmp_buf
#define sigsetjmp(x,y) setjmp(x)
#define siglongjmp longjmp
#endif
/* EXEC_BACKEND defines */
#ifdef EXEC_BACKEND
#define NON_EXEC_STATIC
#else
#define NON_EXEC_STATIC static
#endif
/* /port compatibility functions */
#include "port.h"
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
#endif /* C_H */