1996-10-31 08:10:14 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* c.h
|
1997-09-07 07:04:48 +02:00
|
|
|
* Fundamental C definitions. This is included by every .c file in
|
2001-02-10 03:31:31 +01:00
|
|
|
* PostgreSQL (via either postgres.h or postgres_fe.h, as appropriate).
|
|
|
|
*
|
2002-08-25 19:20:01 +02:00
|
|
|
* 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
|
|
|
*
|
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* 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
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
/*
|
2001-02-10 03:31:31 +01:00
|
|
|
*----------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* TABLE OF CONTENTS
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
2000-03-19 23:08:51 +01:00
|
|
|
* When adding stuff to this file, please try to put stuff
|
1997-09-07 07:04:48 +02:00
|
|
|
* into the relevant section, or add new sections as appropriate.
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* section description
|
|
|
|
* ------- ------------------------------------------------
|
2001-08-24 16:07:50 +02:00
|
|
|
* 0) pg_config.h and standard system headers
|
2017-11-14 19:46:54 +01:00
|
|
|
* 1) compiler characteristics
|
2017-08-16 06:22:32 +02:00
|
|
|
* 2) bool, true, false
|
1997-09-07 07:04:48 +02:00
|
|
|
* 3) standard system types
|
2001-02-10 03:31:31 +01:00
|
|
|
* 4) IsValid macros for system types
|
2017-08-17 18:39:20 +02:00
|
|
|
* 5) offsetof, lengthof, alignment
|
2013-02-01 21:50:04 +01:00
|
|
|
* 6) assertions
|
|
|
|
* 7) widely useful macros
|
|
|
|
* 8) random stuff
|
|
|
|
* 9) system-specific hacks
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
2018-02-15 01:43:33 +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.
|
2001-02-10 03:31:31 +01:00
|
|
|
*
|
|
|
|
*----------------------------------------------------------------
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#ifndef C_H
|
1996-10-31 08:10:14 +01:00
|
|
|
#define C_H
|
|
|
|
|
2012-10-08 03:52:07 +02:00
|
|
|
#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
|
|
|
|
2001-08-24 16:07:50 +02:00
|
|
|
#include "pg_config.h"
|
2003-04-18 03:03:42 +02:00
|
|
|
#include "pg_config_manual.h" /* must be after pg_config.h */
|
2003-05-16 01:39:27 +02:00
|
|
|
#include "pg_config_os.h" /* must be before any system header files */
|
2012-10-08 03:52:07 +02:00
|
|
|
|
2017-11-16 16:36:18 +01:00
|
|
|
/* System header files that should be available everywhere in Postgres */
|
1999-07-17 22:18:55 +02:00
|
|
|
#include <stdio.h>
|
1996-11-14 07:06:39 +01:00
|
|
|
#include <stdlib.h>
|
1999-07-17 22:18:55 +02:00
|
|
|
#include <string.h>
|
1999-01-17 04:22:52 +01:00
|
|
|
#include <stddef.h>
|
|
|
|
#include <stdarg.h>
|
2006-03-05 05:43:57 +01:00
|
|
|
#ifdef HAVE_STRINGS_H
|
2000-11-03 19:43:52 +01:00
|
|
|
#include <strings.h>
|
|
|
|
#endif
|
2009-12-31 20:41:37 +01:00
|
|
|
#include <stdint.h>
|
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 */
|
2003-10-21 17:32:58 +02:00
|
|
|
#endif
|
2017-11-14 19:46:54 +01:00
|
|
|
#include <locale.h>
|
|
|
|
#ifdef ENABLE_NLS
|
|
|
|
#include <libintl.h>
|
|
|
|
#endif
|
1999-01-17 07:20:06 +01:00
|
|
|
|
2017-11-14 19:46:54 +01:00
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* Section 1: compiler characteristics
|
2015-08-08 01:19:02 +02:00
|
|
|
*
|
2017-11-14 19:46:54 +01:00
|
|
|
* 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.
|
2015-08-08 01:19:02 +02:00
|
|
|
*/
|
|
|
|
#ifdef PG_FORCE_DISABLE_INLINE
|
|
|
|
#undef inline
|
|
|
|
#define inline
|
|
|
|
#endif
|
|
|
|
|
2017-11-14 19:46:54 +01:00
|
|
|
/*
|
|
|
|
* 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
|
2019-10-26 21:55:16 +02:00
|
|
|
* XLC: https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.2/com.ibm.xlc131.aix.doc/language_ref/function_attributes.html
|
2019-10-08 07:31:30 +02:00
|
|
|
* XLC: https://www.ibm.com/support/knowledgecenter/SSGH2K_13.1.2/com.ibm.xlc131.aix.doc/language_ref/type_attrib.html
|
2017-11-14 19:46:54 +01:00
|
|
|
*/
|
2001-10-24 23:49:14 +02:00
|
|
|
|
2017-11-14 19:46:54 +01:00
|
|
|
/* only GCC supports the unused attribute */
|
|
|
|
#ifdef __GNUC__
|
|
|
|
#define pg_attribute_unused() __attribute__((unused))
|
|
|
|
#else
|
|
|
|
#define pg_attribute_unused()
|
|
|
|
#endif
|
2005-02-22 05:43:23 +01:00
|
|
|
|
2017-11-14 19:46:54 +01:00
|
|
|
/*
|
|
|
|
* 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
|
2001-06-02 20:25:18 +02:00
|
|
|
#else
|
2017-11-14 19:46:54 +01:00
|
|
|
#define PG_USED_FOR_ASSERTS_ONLY pg_attribute_unused()
|
2001-06-02 20:25:18 +02:00
|
|
|
#endif
|
2005-02-15 02:03:47 +01:00
|
|
|
|
2017-11-14 19:46:54 +01:00
|
|
|
/* GCC and XLC support format attributes */
|
|
|
|
#if defined(__GNUC__) || defined(__IBMC__)
|
|
|
|
#define pg_attribute_format_arg(a) __attribute__((format_arg(a)))
|
2018-08-13 00:46:01 +02:00
|
|
|
#define pg_attribute_printf(f,a) __attribute__((format(PG_PRINTF_ATTRIBUTE, f, a)))
|
2017-11-14 19:46:54 +01:00
|
|
|
#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
|
|
|
/*
|
2017-11-14 19:46:54 +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
|
|
|
*/
|
2017-11-14 19:46:54 +01:00
|
|
|
#define pg_attribute_noreturn()
|
|
|
|
#endif
|
2001-07-03 22:21:50 +02:00
|
|
|
|
2018-01-24 05:07:13 +01:00
|
|
|
/*
|
|
|
|
* 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
|
2017-12-14 00:34:20 +01:00
|
|
|
#elif defined(_MSC_VER)
|
2018-01-24 05:07:13 +01:00
|
|
|
/* MSVC has a special keyword for this */
|
2017-12-14 00:34:20 +01:00
|
|
|
#define pg_attribute_always_inline __forceinline
|
|
|
|
#else
|
2018-01-24 05:07:13 +01:00
|
|
|
/* Otherwise, the best we can do is to say "inline" */
|
|
|
|
#define pg_attribute_always_inline inline
|
2017-12-14 00:34:20 +01:00
|
|
|
#endif
|
|
|
|
|
2017-11-14 19:46:54 +01:00
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
2017-11-14 19:46:54 +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
|
|
|
*
|
2017-11-14 19:46:54 +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
|
|
|
*/
|
2017-11-14 19:46:54 +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
|
1997-09-07 07:04:48 +02:00
|
|
|
* Convert the argument to a string, using the C preprocessor.
|
2017-03-10 00:54:45 +01:00
|
|
|
* CppAsString2
|
|
|
|
* Convert the argument to a string, after one round of macro expansion.
|
1999-05-25 18:15:34 +02:00
|
|
|
* CppConcat
|
1997-09-07 07:04:48 +02:00
|
|
|
* Concatenate two arguments together, using the C preprocessor.
|
1999-04-02 07:10:16 +02:00
|
|
|
*
|
2013-11-30 15:17:08 +01:00
|
|
|
* 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
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#define CppAsString(identifier) #identifier
|
2017-03-10 00:54:45 +01:00
|
|
|
#define CppAsString2(x) CppAsString(x)
|
1997-09-07 07:04:48 +02:00
|
|
|
#define CppConcat(x, y) x##y
|
1998-01-27 16:35:30 +01:00
|
|
|
|
2018-09-22 02:50:18 +02:00
|
|
|
/*
|
|
|
|
* 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)
|
|
|
|
|
1998-01-27 16:35:30 +01:00
|
|
|
/*
|
|
|
|
* 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 */
|
1998-01-27 16:35:30 +01:00
|
|
|
#define dummyret void
|
1999-04-02 07:10:16 +02:00
|
|
|
#else
|
|
|
|
#define dummyret char
|
1996-10-31 08:10:14 +01:00
|
|
|
#endif
|
|
|
|
|
Fix -Wcast-function-type warnings
Three groups of issues needed to be addressed:
load_external_function() and related functions returned PGFunction,
even though not necessarily all callers are looking for a function of
type PGFunction. Since these functions are really just wrappers
around dlsym(), change to return void * just like dlsym().
In dynahash.c, we are using strlcpy() where a function with a
signature like memcpy() is expected. This should be safe, as the new
comment there explains, but the cast needs to be augmented to avoid
the warning.
In PL/Python, methods all need to be cast to PyCFunction, per Python
API, but this now runs afoul of these warnings. (This issue also
exists in core CPython.)
To fix the second and third case, we add a new type pg_funcptr_t that
is defined specifically so that gcc accepts it as a special function
pointer that can be cast to any other function pointer without the
warning.
Also add -Wcast-function-type to the standard warning flags, subject
to configure check.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/1e97628e-6447-b4fd-e230-d109cec2d584%402ndquadrant.com
2020-07-14 19:36:30 +02:00
|
|
|
/*
|
|
|
|
* Generic function pointer. This can be used in the rare cases where it's
|
|
|
|
* necessary to cast a function pointer to a seemingly incompatible function
|
|
|
|
* pointer type while avoiding gcc's -Wcast-function-type warnings.
|
|
|
|
*/
|
|
|
|
typedef void (*pg_funcptr_t) (void);
|
|
|
|
|
2020-02-21 20:30:21 +01:00
|
|
|
/*
|
|
|
|
* We require C99, hence the compiler should understand flexible array
|
|
|
|
* members. However, for documentation purposes we still consider it to be
|
|
|
|
* project style to write "field[FLEXIBLE_ARRAY_MEMBER]" not just "field[]".
|
|
|
|
* When computing the size of such an object, use "offsetof(struct s, f)"
|
|
|
|
* for portability. Don't use "offsetof(struct s, f[0])", as this doesn't
|
|
|
|
* work with MSVC and with C++ compilers.
|
|
|
|
*/
|
|
|
|
#define FLEXIBLE_ARRAY_MEMBER /* empty */
|
|
|
|
|
2016-04-14 01:42:01 +02:00
|
|
|
/* 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
|
|
|
|
|
2017-11-14 19:46:54 +01:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/* ----------------------------------------------------------------
|
2017-08-16 06:22:32 +02:00
|
|
|
* Section 2: bool, true, false
|
2001-02-10 03:31:31 +01:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
2001-08-28 01:02:25 +02:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/*
|
|
|
|
* bool
|
|
|
|
* Boolean value, either true or false.
|
|
|
|
*
|
Fix ecpglib.h to declare bool consistently with c.h.
This completes the task begun in commit 1408d5d86, to synchronize
ECPG's exported definitions with the definition of bool used by
c.h (and, therefore, the one actually in use in the ECPG library).
On practically all modern platforms, ecpglib.h will now just
include <stdbool.h>, which should surprise nobody anymore.
That removes a header-inclusion-order hazard for ECPG clients,
who previously might get build failures or unexpected behavior
depending on whether they'd included <stdbool.h> themselves,
and if so, whether before or after ecpglib.h.
On platforms where sizeof(_Bool) is not 1 (only old PPC-based
Mac systems, as far as I know), things are still messy, as
inclusion of <stdbool.h> could still break ECPG client code.
There doesn't seem to be any clean fix for that, and given the
probably-negligible population of users who would care anymore,
it's not clear we should go far out of our way to cope with it.
This change at least fixes some header-inclusion-order hazards
for our own code, since c.h and ecpglib.h previously disagreed
on whether bool should be char or unsigned char.
To implement this with minimal invasion of ECPG client namespace,
move the choice of whether to rely on <stdbool.h> into configure,
and have it export a configuration symbol PG_USE_STDBOOL.
ecpglib.h no longer exports definitions for TRUE and FALSE,
only their lowercase brethren. We could undo that if we get
push-back about it.
Ideally we'd back-patch this as far as v11, which is where c.h
started to rely on <stdbool.h>. But the odds of creating problems
for formerly-working ECPG client code seem about as large as the
odds of fixing any non-working cases, so we'll just do this in HEAD.
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com
2019-11-12 19:00:04 +01:00
|
|
|
* We use stdbool.h if available and its bool has size 1. That's useful for
|
2018-03-23 01:42:25 +01:00
|
|
|
* 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.
|
Fix ecpglib.h to declare bool consistently with c.h.
This completes the task begun in commit 1408d5d86, to synchronize
ECPG's exported definitions with the definition of bool used by
c.h (and, therefore, the one actually in use in the ECPG library).
On practically all modern platforms, ecpglib.h will now just
include <stdbool.h>, which should surprise nobody anymore.
That removes a header-inclusion-order hazard for ECPG clients,
who previously might get build failures or unexpected behavior
depending on whether they'd included <stdbool.h> themselves,
and if so, whether before or after ecpglib.h.
On platforms where sizeof(_Bool) is not 1 (only old PPC-based
Mac systems, as far as I know), things are still messy, as
inclusion of <stdbool.h> could still break ECPG client code.
There doesn't seem to be any clean fix for that, and given the
probably-negligible population of users who would care anymore,
it's not clear we should go far out of our way to cope with it.
This change at least fixes some header-inclusion-order hazards
for our own code, since c.h and ecpglib.h previously disagreed
on whether bool should be char or unsigned char.
To implement this with minimal invasion of ECPG client namespace,
move the choice of whether to rely on <stdbool.h> into configure,
and have it export a configuration symbol PG_USE_STDBOOL.
ecpglib.h no longer exports definitions for TRUE and FALSE,
only their lowercase brethren. We could undo that if we get
push-back about it.
Ideally we'd back-patch this as far as v11, which is where c.h
started to rely on <stdbool.h>. But the odds of creating problems
for formerly-working ECPG client code seem about as large as the
odds of fixing any non-working cases, so we'll just do this in HEAD.
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com
2019-11-12 19:00:04 +01:00
|
|
|
*
|
|
|
|
* See also the version of this code in src/interfaces/ecpg/include/ecpglib.h.
|
2001-02-10 03:31:31 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __cplusplus
|
2001-08-28 01:02:25 +02:00
|
|
|
|
Fix ecpglib.h to declare bool consistently with c.h.
This completes the task begun in commit 1408d5d86, to synchronize
ECPG's exported definitions with the definition of bool used by
c.h (and, therefore, the one actually in use in the ECPG library).
On practically all modern platforms, ecpglib.h will now just
include <stdbool.h>, which should surprise nobody anymore.
That removes a header-inclusion-order hazard for ECPG clients,
who previously might get build failures or unexpected behavior
depending on whether they'd included <stdbool.h> themselves,
and if so, whether before or after ecpglib.h.
On platforms where sizeof(_Bool) is not 1 (only old PPC-based
Mac systems, as far as I know), things are still messy, as
inclusion of <stdbool.h> could still break ECPG client code.
There doesn't seem to be any clean fix for that, and given the
probably-negligible population of users who would care anymore,
it's not clear we should go far out of our way to cope with it.
This change at least fixes some header-inclusion-order hazards
for our own code, since c.h and ecpglib.h previously disagreed
on whether bool should be char or unsigned char.
To implement this with minimal invasion of ECPG client namespace,
move the choice of whether to rely on <stdbool.h> into configure,
and have it export a configuration symbol PG_USE_STDBOOL.
ecpglib.h no longer exports definitions for TRUE and FALSE,
only their lowercase brethren. We could undo that if we get
push-back about it.
Ideally we'd back-patch this as far as v11, which is where c.h
started to rely on <stdbool.h>. But the odds of creating problems
for formerly-working ECPG client code seem about as large as the
odds of fixing any non-working cases, so we'll just do this in HEAD.
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com
2019-11-12 19:00:04 +01:00
|
|
|
#ifdef PG_USE_STDBOOL
|
2018-03-23 01:42:25 +01:00
|
|
|
#include <stdbool.h>
|
|
|
|
#else
|
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
#ifndef bool
|
2019-02-20 22:31:02 +01:00
|
|
|
typedef unsigned char bool;
|
2001-08-28 01:02:25 +02:00
|
|
|
#endif
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
#ifndef true
|
|
|
|
#define true ((bool) 1)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef false
|
|
|
|
#define false ((bool) 0)
|
|
|
|
#endif
|
2017-11-14 19:46:54 +01:00
|
|
|
|
Fix ecpglib.h to declare bool consistently with c.h.
This completes the task begun in commit 1408d5d86, to synchronize
ECPG's exported definitions with the definition of bool used by
c.h (and, therefore, the one actually in use in the ECPG library).
On practically all modern platforms, ecpglib.h will now just
include <stdbool.h>, which should surprise nobody anymore.
That removes a header-inclusion-order hazard for ECPG clients,
who previously might get build failures or unexpected behavior
depending on whether they'd included <stdbool.h> themselves,
and if so, whether before or after ecpglib.h.
On platforms where sizeof(_Bool) is not 1 (only old PPC-based
Mac systems, as far as I know), things are still messy, as
inclusion of <stdbool.h> could still break ECPG client code.
There doesn't seem to be any clean fix for that, and given the
probably-negligible population of users who would care anymore,
it's not clear we should go far out of our way to cope with it.
This change at least fixes some header-inclusion-order hazards
for our own code, since c.h and ecpglib.h previously disagreed
on whether bool should be char or unsigned char.
To implement this with minimal invasion of ECPG client namespace,
move the choice of whether to rely on <stdbool.h> into configure,
and have it export a configuration symbol PG_USE_STDBOOL.
ecpglib.h no longer exports definitions for TRUE and FALSE,
only their lowercase brethren. We could undo that if we get
push-back about it.
Ideally we'd back-patch this as far as v11, which is where c.h
started to rely on <stdbool.h>. But the odds of creating problems
for formerly-working ECPG client code seem about as large as the
odds of fixing any non-working cases, so we'll just do this in HEAD.
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com
2019-11-12 19:00:04 +01:00
|
|
|
#endif /* not PG_USE_STDBOOL */
|
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++ */
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/* ----------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Section 3: standard system types
|
1996-10-31 08:10:14 +01:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
1999-04-02 07:10:16 +02:00
|
|
|
/*
|
1999-05-25 18:15:34 +02:00
|
|
|
* Pointer
|
1999-04-02 07:10:16 +02:00
|
|
|
* 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
|
1998-01-26 02:42:53 +01:00
|
|
|
* Signed integer, EXACTLY N BITS IN SIZE,
|
|
|
|
* used for numerical computations and the
|
|
|
|
* frontend/backend protocol.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
2001-12-02 12:38:40 +01:00
|
|
|
#ifndef HAVE_INT8
|
1998-01-26 02:42:53 +01:00
|
|
|
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 */
|
2001-02-10 03:31:31 +01:00
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/*
|
1999-05-25 18:15:34 +02:00
|
|
|
* uintN
|
1998-01-26 02:42:53 +01:00
|
|
|
* Unsigned integer, EXACTLY N BITS IN SIZE,
|
|
|
|
* used for numerical computations and the
|
|
|
|
* frontend/backend protocol.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
2001-12-02 12:38:40 +01:00
|
|
|
#ifndef HAVE_UINT8
|
1998-01-26 02:42:53 +01:00
|
|
|
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
|
1997-09-07 07:04:48 +02:00
|
|
|
* Unit of bitwise operation, AT LEAST N BITS IN SIZE.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
1997-09-08 04:41:22 +02:00
|
|
|
typedef uint8 bits8; /* >= 8 bits */
|
|
|
|
typedef uint16 bits16; /* >= 16 bits */
|
|
|
|
typedef uint32 bits32; /* >= 32 bits */
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2000-05-28 19:56:29 +02:00
|
|
|
/*
|
2001-02-10 03:31:31 +01:00
|
|
|
* 64-bit integers
|
2000-05-28 19:56:29 +02:00
|
|
|
*/
|
|
|
|
#ifdef HAVE_LONG_INT_64
|
|
|
|
/* Plain "long int" fits, use it */
|
2001-12-02 12:38:40 +01:00
|
|
|
|
|
|
|
#ifndef HAVE_INT64
|
2000-05-28 19:56:29 +02:00
|
|
|
typedef long int int64;
|
2001-11-15 17:09:34 +01:00
|
|
|
#endif
|
2001-12-02 12:38:40 +01:00
|
|
|
#ifndef HAVE_UINT64
|
2001-01-09 17:07:14 +01:00
|
|
|
typedef unsigned long int uint64;
|
2001-11-15 17:09:34 +01:00
|
|
|
#endif
|
Make [U]INT64CONST safe for use in #if conditions.
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
2017-09-01 21:14:18 +02:00
|
|
|
#define INT64CONST(x) (x##L)
|
|
|
|
#define UINT64CONST(x) (x##UL)
|
2001-12-02 12:38:40 +01:00
|
|
|
#elif defined(HAVE_LONG_LONG_INT_64)
|
2000-05-28 19:56:29 +02:00
|
|
|
/* We have working support for "long long int", use that */
|
2001-12-02 12:38:40 +01:00
|
|
|
|
|
|
|
#ifndef HAVE_INT64
|
2000-05-28 19:56:29 +02:00
|
|
|
typedef long long int int64;
|
2001-11-15 17:09:34 +01:00
|
|
|
#endif
|
2001-12-02 12:38:40 +01:00
|
|
|
#ifndef HAVE_UINT64
|
2001-01-09 17:07:14 +01:00
|
|
|
typedef unsigned long long int uint64;
|
2001-11-15 17:09:34 +01:00
|
|
|
#endif
|
Make [U]INT64CONST safe for use in #if conditions.
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
2017-09-01 21:14:18 +02:00
|
|
|
#define INT64CONST(x) (x##LL)
|
|
|
|
#define UINT64CONST(x) (x##ULL)
|
2010-01-07 05:53:35 +01:00
|
|
|
#else
|
|
|
|
/* neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 */
|
|
|
|
#error must have a working 64-bit integer datatype
|
2001-11-15 17:09:34 +01:00
|
|
|
#endif
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2014-08-21 08:56:44 +02:00
|
|
|
/* snprintf format strings to use for 64-bit integers */
|
|
|
|
#define INT64_FORMAT "%" INT64_MODIFIER "d"
|
|
|
|
#define UINT64_FORMAT "%" INT64_MODIFIER "u"
|
2002-04-23 17:45:30 +02:00
|
|
|
|
Add, optional, support for 128bit integers.
We will, for the foreseeable future, not expose 128 bit datatypes to
SQL. But being able to use 128bit math will allow us, in a later patch,
to use 128bit accumulators for some aggregates; leading to noticeable
speedups over using numeric.
So far we only detect a gcc/clang extension that supports 128bit math,
but no 128bit literals, and no *printf support. We might want to expand
this in the future to further compilers; if there are any that that
provide similar support.
Discussion: 544BB5F1.50709@proxel.se
Author: Andreas Karlsson, with significant editorializing by me
Reviewed-By: Peter Geoghegan, Oskari Saarenmaa
2015-03-20 10:26:17 +01:00
|
|
|
/*
|
|
|
|
* 128-bit signed and unsigned integers
|
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.
|
Add, optional, support for 128bit integers.
We will, for the foreseeable future, not expose 128 bit datatypes to
SQL. But being able to use 128bit math will allow us, in a later patch,
to use 128bit accumulators for some aggregates; leading to noticeable
speedups over using numeric.
So far we only detect a gcc/clang extension that supports 128bit math,
but no 128bit literals, and no *printf support. We might want to expand
this in the future to further compilers; if there are any that that
provide similar support.
Discussion: 544BB5F1.50709@proxel.se
Author: Andreas Karlsson, with significant editorializing by me
Reviewed-By: Peter Geoghegan, Oskari Saarenmaa
2015-03-20 10:26:17 +01:00
|
|
|
*/
|
|
|
|
#if defined(PG_INT128_TYPE)
|
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)
|
2019-05-22 19:04:48 +02:00
|
|
|
pg_attribute_aligned(MAXIMUM_ALIGNOF)
|
2017-11-14 21:03:55 +01:00
|
|
|
#endif
|
2019-05-22 19:04:48 +02:00
|
|
|
;
|
2017-11-14 21:03:55 +01:00
|
|
|
|
|
|
|
typedef unsigned PG_INT128_TYPE uint128
|
|
|
|
#if defined(pg_attribute_aligned)
|
2019-05-22 19:04:48 +02:00
|
|
|
pg_attribute_aligned(MAXIMUM_ALIGNOF)
|
2017-11-14 21:03:55 +01:00
|
|
|
#endif
|
2019-05-22 19:04:48 +02:00
|
|
|
;
|
2017-11-14 21:03:55 +01:00
|
|
|
|
|
|
|
#endif
|
Add, optional, support for 128bit integers.
We will, for the foreseeable future, not expose 128 bit datatypes to
SQL. But being able to use 128bit math will allow us, in a later patch,
to use 128bit accumulators for some aggregates; leading to noticeable
speedups over using numeric.
So far we only detect a gcc/clang extension that supports 128bit math,
but no 128bit literals, and no *printf support. We might want to expand
this in the future to further compilers; if there are any that that
provide similar support.
Discussion: 544BB5F1.50709@proxel.se
Author: Andreas Karlsson, with significant editorializing by me
Reviewed-By: Peter Geoghegan, Oskari Saarenmaa
2015-03-20 10:26:17 +01:00
|
|
|
#endif
|
|
|
|
|
2015-04-02 17:43:35 +02:00
|
|
|
/*
|
2020-02-21 09:14:03 +01:00
|
|
|
* stdint.h limits aren't guaranteed to have compatible types with our fixed
|
|
|
|
* width types. So just define our own.
|
2015-04-02 17:43:35 +02:00
|
|
|
*/
|
|
|
|
#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)
|
Make [U]INT64CONST safe for use in #if conditions.
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
2017-09-01 21:14:18 +02:00
|
|
|
#define PG_UINT32_MAX (0xFFFFFFFFU)
|
2015-04-02 17:43:35 +02:00
|
|
|
#define PG_INT64_MIN (-INT64CONST(0x7FFFFFFFFFFFFFFF) - 1)
|
|
|
|
#define PG_INT64_MAX INT64CONST(0x7FFFFFFFFFFFFFFF)
|
|
|
|
#define PG_UINT64_MAX UINT64CONST(0xFFFFFFFFFFFFFFFF)
|
|
|
|
|
2017-02-23 17:40:12 +01:00
|
|
|
/*
|
|
|
|
* We now always use int64 timestamps, but keep this symbol defined for the
|
|
|
|
* benefit of external code that might test it.
|
|
|
|
*/
|
2015-04-02 17:43:35 +02:00
|
|
|
#define HAVE_INT64_TIMESTAMP
|
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/*
|
2001-02-10 03:31:31 +01:00
|
|
|
* Size
|
|
|
|
* Size of any memory resident object, as returned by sizeof.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
2001-02-10 03:31:31 +01:00
|
|
|
typedef size_t Size;
|
2000-05-28 19:56:29 +02:00
|
|
|
|
|
|
|
/*
|
2001-02-10 03:31:31 +01:00
|
|
|
* Index
|
|
|
|
* Index into any memory resident array.
|
2000-05-28 19:56:29 +02:00
|
|
|
*
|
2001-02-10 03:31:31 +01:00
|
|
|
* Note:
|
|
|
|
* Indices are non negative.
|
2000-05-28 19:56:29 +02:00
|
|
|
*/
|
2001-02-10 03:31:31 +01:00
|
|
|
typedef unsigned int Index;
|
2000-05-28 19:56:29 +02:00
|
|
|
|
|
|
|
/*
|
2001-02-10 03:31:31 +01:00
|
|
|
* Offset
|
|
|
|
* Offset into any memory resident array.
|
2000-05-28 19:56:29 +02:00
|
|
|
*
|
2001-02-10 03:31:31 +01:00
|
|
|
* Note:
|
|
|
|
* This differs from an Index in that an Index is always
|
|
|
|
* non negative, whereas Offset may be negative.
|
2000-05-28 19:56:29 +02:00
|
|
|
*/
|
2001-02-10 03:31:31 +01:00
|
|
|
typedef signed int Offset;
|
2000-05-28 19:56:29 +02:00
|
|
|
|
|
|
|
/*
|
2001-02-10 03:31:31 +01:00
|
|
|
* Common Postgres datatype names (as used in the catalogs)
|
2000-05-28 19:56:29 +02:00
|
|
|
*/
|
2001-02-10 03:31:31 +01:00
|
|
|
typedef float float4;
|
|
|
|
typedef double float8;
|
2000-05-28 19:56:29 +02:00
|
|
|
|
2019-11-27 11:21:02 +01:00
|
|
|
#ifdef USE_FLOAT8_BYVAL
|
|
|
|
#define FLOAT8PASSBYVAL true
|
|
|
|
#else
|
|
|
|
#define FLOAT8PASSBYVAL false
|
|
|
|
#endif
|
|
|
|
|
2000-05-28 19:56:29 +02:00
|
|
|
/*
|
2005-04-28 23:47:18 +02:00
|
|
|
* Oid, RegProcedure, TransactionId, SubTransactionId, MultiXactId,
|
2005-06-28 07:09:14 +02:00
|
|
|
* CommandId
|
2000-05-28 19:56:29 +02:00
|
|
|
*/
|
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/* typedef Oid is in postgres_ext.h */
|
2000-05-28 19:56:29 +02:00
|
|
|
|
2002-04-25 04:56:56 +02:00
|
|
|
/*
|
|
|
|
* regproc is the type name used in the include/catalog headers, but
|
|
|
|
* RegProcedure is the preferred name in C code.
|
|
|
|
*/
|
2001-02-10 03:31:31 +01:00
|
|
|
typedef Oid regproc;
|
2002-04-25 04:56:56 +02:00
|
|
|
typedef regproc RegProcedure;
|
2000-05-28 19:56:29 +02:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
typedef uint32 TransactionId;
|
2000-05-28 19:56:29 +02:00
|
|
|
|
2007-09-05 20:10:48 +02:00
|
|
|
typedef uint32 LocalTransactionId;
|
|
|
|
|
2004-09-16 18:58:44 +02:00
|
|
|
typedef uint32 SubTransactionId;
|
|
|
|
|
|
|
|
#define InvalidSubTransactionId ((SubTransactionId) 0)
|
|
|
|
#define TopSubTransactionId ((SubTransactionId) 1)
|
|
|
|
|
2005-04-28 23:47:18 +02:00
|
|
|
/* MultiXactId must be equivalent to TransactionId, to fit in t_xmax */
|
|
|
|
typedef TransactionId MultiXactId;
|
|
|
|
|
2005-06-08 17:50:28 +02:00
|
|
|
typedef uint32 MultiXactOffset;
|
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
typedef uint32 CommandId;
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2001-08-24 01:06:38 +02:00
|
|
|
#define FirstCommandId ((CommandId) 0)
|
2013-09-09 22:25:29 +02:00
|
|
|
#define InvalidCommandId (~(CommandId)0)
|
1996-10-31 08:10:14 +01:00
|
|
|
|
|
|
|
/*
|
2001-02-10 03:31:31 +01:00
|
|
|
* Array indexing support
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
2001-02-10 03:31:31 +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
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/* ----------------
|
|
|
|
* Variable-length datatypes all share the 'struct varlena' header.
|
2000-05-28 19:56:29 +02:00
|
|
|
*
|
2002-08-25 19:20:01 +02:00
|
|
|
* NOTE: for TOASTable types, this is an oversimplification, since the value
|
2014-05-06 18:12:18 +02:00
|
|
|
* may be compressed or moved out-of-line. However datatype-specific routines
|
2002-08-25 19:20:01 +02:00
|
|
|
* are mostly content to deal with de-TOASTed values only, and of course
|
2007-02-28 00:48:10 +01:00
|
|
|
* client-side routines should never see a TOASTed value. But even in a
|
2017-03-13 00:35:33 +01:00
|
|
|
* 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.
|
2001-02-10 03:31:31 +01:00
|
|
|
* ----------------
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
2001-02-10 03:31:31 +01:00
|
|
|
struct varlena
|
|
|
|
{
|
2008-02-23 20:11:45 +01:00
|
|
|
char vl_len_[4]; /* Do not touch this field directly! */
|
2015-02-20 22:51:53 +01:00
|
|
|
char vl_dat[FLEXIBLE_ARRAY_MEMBER]; /* Data content is here */
|
2001-02-10 03:31:31 +01:00
|
|
|
};
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
#define VARHDRSZ ((int32) sizeof(int32))
|
1996-10-31 08:10:14 +01:00
|
|
|
|
|
|
|
/*
|
2001-02-10 03:31:31 +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
|
2017-03-13 00:35:30 +01:00
|
|
|
* always VARSIZE_ANY_EXHDR(ptr).
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
2001-02-10 03:31:31 +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
|
|
|
|
|
|
|
/*
|
2005-03-29 02:17:27 +02:00
|
|
|
* Specialized array types. These are physically laid out just the same
|
|
|
|
* as regular arrays (so that the regular array subscripting code works
|
2014-05-06 18:12:18 +02:00
|
|
|
* with them). They exist as distinct types mostly for historical reasons:
|
2005-03-29 02:17:27 +02:00
|
|
|
* 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
|
|
|
*/
|
2005-03-29 02:17:27 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
2007-02-28 00:48:10 +01:00
|
|
|
int32 vl_len_; /* these fields must match ArrayType! */
|
2005-11-17 23:14:56 +01:00
|
|
|
int ndim; /* always 1 for int2vector */
|
|
|
|
int32 dataoffset; /* always 0 for int2vector */
|
2005-03-29 02:17:27 +02:00
|
|
|
Oid elemtype;
|
|
|
|
int dim1;
|
|
|
|
int lbound1;
|
2015-02-20 06:11:42 +01:00
|
|
|
int16 values[FLEXIBLE_ARRAY_MEMBER];
|
|
|
|
} int2vector;
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2005-03-29 02:17:27 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
2007-02-28 00:48:10 +01:00
|
|
|
int32 vl_len_; /* these fields must match ArrayType! */
|
2005-11-17 23:14:56 +01:00
|
|
|
int ndim; /* always 1 for oidvector */
|
|
|
|
int32 dataoffset; /* always 0 for oidvector */
|
2005-03-29 02:17:27 +02:00
|
|
|
Oid elemtype;
|
|
|
|
int dim1;
|
|
|
|
int lbound1;
|
2015-02-20 06:11:42 +01:00
|
|
|
Oid values[FLEXIBLE_ARRAY_MEMBER];
|
|
|
|
} oidvector;
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2000-07-17 05:05:41 +02: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.
|
2000-07-17 05:05:41 +02: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
|
|
|
typedef struct nameData
|
2001-02-10 03:31:31 +01:00
|
|
|
{
|
|
|
|
char data[NAMEDATALEN];
|
|
|
|
} NameData;
|
|
|
|
typedef NameData *Name;
|
2000-07-17 05:05:41 +02:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
#define NameStr(name) ((name).data)
|
2000-07-17 05:05:41 +02:00
|
|
|
|
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/* ----------------------------------------------------------------
|
2001-02-10 03:31:31 +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
|
1997-09-07 07:04:48 +02:00
|
|
|
* True iff bool is valid.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02: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
|
1997-09-07 07:04:48 +02:00
|
|
|
* True iff pointer is valid.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
2012-02-28 11:42:08 +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
|
1997-09-07 07:04:48 +02:00
|
|
|
* True iff pointer is properly aligned to point to the given type.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#define PointerIsAligned(pointer, type) \
|
2013-10-21 03:04:52 +02:00
|
|
|
(((uintptr_t)(pointer) % (sizeof (type))) == 0)
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2017-01-24 22:42:58 +01:00
|
|
|
#define OffsetToPointer(base, offset) \
|
|
|
|
((void *)((char *) base + offset))
|
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
#define OidIsValid(objectId) ((bool) ((objectId) != InvalidOid))
|
|
|
|
|
|
|
|
#define RegProcedureIsValid(p) OidIsValid(p)
|
|
|
|
|
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/* ----------------------------------------------------------------
|
2017-08-17 18:39:20 +02:00
|
|
|
* Section 5: offsetof, lengthof, alignment
|
1996-10-31 08:10:14 +01:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
/*
|
1999-05-25 18:15:34 +02:00
|
|
|
* offsetof
|
1997-09-07 07:04:48 +02:00
|
|
|
* Offset of a structure/union field within that structure/union.
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
1997-09-07 07:04:48 +02: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
|
1997-09-07 07:04:48 +02:00
|
|
|
* Number of elements in an array.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#define lengthof(array) (sizeof (array) / sizeof ((array)[0]))
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/* ----------------
|
|
|
|
* Alignment macros: align a length or address appropriately for a given type.
|
2007-02-05 05:22:18 +01:00
|
|
|
* 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
|
|
|
*
|
2007-02-05 05:22:18 +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.
|
2017-11-14 19:46:54 +01:00
|
|
|
*
|
|
|
|
* NOTE: MAXIMUM_ALIGNOF, and hence MAXALIGN(), intentionally exclude any
|
|
|
|
* larger-than-8-byte types the compiler might have.
|
2001-02-10 03:31:31 +01:00
|
|
|
* ----------------
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
|
|
|
|
2003-09-21 19:57:21 +02:00
|
|
|
#define TYPEALIGN(ALIGNVAL,LEN) \
|
2013-10-21 03:04:52 +02:00
|
|
|
(((uintptr_t) (LEN) + ((ALIGNVAL) - 1)) & ~((uintptr_t) ((ALIGNVAL) - 1)))
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2001-02-10 03:31:31 +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))
|
2003-09-21 19:57:21 +02:00
|
|
|
/* MAXALIGN covers only built-in types, not buffers */
|
|
|
|
#define BUFFERALIGN(LEN) TYPEALIGN(ALIGNOF_BUFFER, (LEN))
|
Align buffer descriptors to cache line boundaries.
Benchmarks has shown that aligning the buffer descriptor array to
cache lines is important for scalability; especially on bigger,
multi-socket, machines.
Currently the array sometimes already happens to be aligned by
happenstance, depending how large previous shared memory allocations
were. That can lead to wildly varying performance results after minor
configuration changes.
In addition to aligning the start of descriptor array, also force the
size of individual descriptors to be of a common cache line size (64
bytes). That happens to already be the case on 64bit platforms, but
this way we can change the struct BufferDesc more easily.
As the alignment primarily matters in highly concurrent workloads
which probably all are 64bit these days, and the space wastage of
element alignment would be a bit more noticeable on 32bit systems, we
don't force the stride to be cacheline sized on 32bit platforms for
now. If somebody does actual performance testing, we can reevaluate
that decision by changing the definition of BUFFERDESC_PADDED_SIZE.
Discussion: 20140202151319.GD32123@awork2.anarazel.de
Per discussion with Bruce Momjan, Tom Lane, Robert Haas, and Peter
Geoghegan.
2015-01-29 17:49:03 +01:00
|
|
|
#define CACHELINEALIGN(LEN) TYPEALIGN(PG_CACHE_LINE_SIZE, (LEN))
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2007-02-05 05:22:18 +01:00
|
|
|
#define TYPEALIGN_DOWN(ALIGNVAL,LEN) \
|
2013-10-21 03:04:52 +02:00
|
|
|
(((uintptr_t) (LEN)) & ~((uintptr_t) ((ALIGNVAL) - 1)))
|
2007-02-05 05:22:18 +01:00
|
|
|
|
|
|
|
#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))
|
2017-08-16 20:52:38 +02:00
|
|
|
#define BUFFERALIGN_DOWN(LEN) TYPEALIGN_DOWN(ALIGNOF_BUFFER, (LEN))
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2013-10-08 00:59:57 +02:00
|
|
|
/*
|
2013-10-21 03:04:52 +02:00
|
|
|
* The above macros will not work with types wider than uintptr_t, like with
|
2013-10-08 00:59:57 +02:00
|
|
|
* 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))
|
|
|
|
|
2017-10-13 20:44:51 +02:00
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/* ----------------------------------------------------------------
|
2013-02-01 21:50:04 +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
|
|
|
|
|
2014-12-08 20:28:09 +01:00
|
|
|
#define Assert(condition) ((void)true)
|
2013-02-01 21:50:04 +01:00
|
|
|
#define AssertMacro(condition) ((void)true)
|
2014-12-08 20:28:09 +01:00
|
|
|
#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)
|
2014-12-08 20:28:09 +01:00
|
|
|
#define Trap(condition, errorType) ((void)true)
|
2014-05-06 18:12:18 +02:00
|
|
|
#define TrapMacro(condition, errorType) (true)
|
2013-06-28 15:30:38 +02:00
|
|
|
|
2013-02-01 21:50:04 +01:00
|
|
|
#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)
|
2017-11-14 19:46:54 +01:00
|
|
|
|
2013-05-29 22:58:43 +02:00
|
|
|
#else /* USE_ASSERT_CHECKING && !FRONTEND */
|
2013-02-01 21:50:04 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Trap
|
|
|
|
* Generates an exception if the given condition is true.
|
|
|
|
*/
|
|
|
|
#define Trap(condition, errorType) \
|
|
|
|
do { \
|
2014-06-20 11:06:42 +02:00
|
|
|
if (condition) \
|
2019-08-17 12:36:30 +02:00
|
|
|
ExceptionalCondition(#condition, (errorType), \
|
2013-02-01 21:50:04 +01:00
|
|
|
__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) \
|
2014-06-20 11:06:42 +02:00
|
|
|
((bool) (! (condition) || \
|
2019-08-17 12:36:30 +02:00
|
|
|
(ExceptionalCondition(#condition, (errorType), \
|
2013-02-01 21:50:04 +01:00
|
|
|
__FILE__, __LINE__), 0)))
|
|
|
|
|
|
|
|
#define Assert(condition) \
|
2019-08-17 12:36:30 +02:00
|
|
|
do { \
|
|
|
|
if (!(condition)) \
|
|
|
|
ExceptionalCondition(#condition, "FailedAssertion", \
|
|
|
|
__FILE__, __LINE__); \
|
|
|
|
} while (0)
|
2013-02-01 21:50:04 +01:00
|
|
|
|
|
|
|
#define AssertMacro(condition) \
|
2019-08-17 12:36:30 +02:00
|
|
|
((void) ((condition) || \
|
|
|
|
(ExceptionalCondition(#condition, "FailedAssertion", \
|
|
|
|
__FILE__, __LINE__), 0)))
|
2013-02-01 21:50:04 +01:00
|
|
|
|
|
|
|
#define AssertArg(condition) \
|
2019-08-17 12:36:30 +02:00
|
|
|
do { \
|
|
|
|
if (!(condition)) \
|
|
|
|
ExceptionalCondition(#condition, "BadArgument", \
|
|
|
|
__FILE__, __LINE__); \
|
|
|
|
} while (0)
|
2013-02-01 21:50:04 +01:00
|
|
|
|
|
|
|
#define AssertState(condition) \
|
2019-08-17 12:36:30 +02:00
|
|
|
do { \
|
|
|
|
if (!(condition)) \
|
|
|
|
ExceptionalCondition(#condition, "BadState", \
|
|
|
|
__FILE__, __LINE__); \
|
|
|
|
} while (0)
|
2013-02-01 21:50:04 +01:00
|
|
|
|
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 */
|
2013-02-01 21:50:04 +01:00
|
|
|
|
2018-02-15 01:43:33 +01:00
|
|
|
/*
|
|
|
|
* 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,
|
2019-05-22 19:04:48 +02:00
|
|
|
const char *errorType,
|
|
|
|
const char *fileName, int lineNumber) pg_attribute_noreturn();
|
2018-02-15 01:43:33 +01:00
|
|
|
#endif
|
|
|
|
|
2013-02-01 21:50:04 +01:00
|
|
|
/*
|
|
|
|
* 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
|
2020-02-03 06:48:42 +01:00
|
|
|
* placement restrictions. Macros StaticAssertStmt() and StaticAssertExpr()
|
|
|
|
* make it safe to use as a statement or in an expression, respectively.
|
|
|
|
* The macro StaticAssertDecl() is suitable for use at file scope (outside of
|
|
|
|
* any function).
|
2013-02-01 21:50:04 +01:00
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
2020-03-23 04:52:37 +01:00
|
|
|
#ifndef __cplusplus
|
|
|
|
#ifdef HAVE__STATIC_ASSERT
|
2013-02-01 21:50:04 +01:00
|
|
|
#define StaticAssertStmt(condition, errmessage) \
|
|
|
|
do { _Static_assert(condition, errmessage); } while(0)
|
|
|
|
#define StaticAssertExpr(condition, errmessage) \
|
2018-02-15 19:41:30 +01:00
|
|
|
((void) ({ StaticAssertStmt(condition, errmessage); true; }))
|
2020-02-03 06:48:42 +01:00
|
|
|
#define StaticAssertDecl(condition, errmessage) \
|
|
|
|
_Static_assert(condition, errmessage)
|
2020-03-23 04:52:37 +01:00
|
|
|
#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)
|
|
|
|
#define StaticAssertDecl(condition, errmessage) \
|
|
|
|
extern void static_assert_func(int static_assert_failure[(condition) ? 1 : -1])
|
|
|
|
#endif /* HAVE__STATIC_ASSERT */
|
|
|
|
#else /* C++ */
|
|
|
|
#if defined(__cpp_static_assert) && __cpp_static_assert >= 200410
|
2016-08-30 18:00:00 +02:00
|
|
|
#define StaticAssertStmt(condition, errmessage) \
|
|
|
|
static_assert(condition, errmessage)
|
|
|
|
#define StaticAssertExpr(condition, errmessage) \
|
2018-02-19 04:20:54 +01:00
|
|
|
({ static_assert(condition, errmessage); })
|
2020-02-03 06:48:42 +01:00
|
|
|
#define StaticAssertDecl(condition, errmessage) \
|
|
|
|
static_assert(condition, errmessage)
|
2020-03-23 04:52:37 +01:00
|
|
|
#else /* !__cpp_static_assert */
|
2016-08-30 18:00:00 +02:00
|
|
|
#define StaticAssertStmt(condition, errmessage) \
|
2020-03-23 04:52:37 +01:00
|
|
|
do { struct static_assert_struct { int static_assert_failure : (condition) ? 1 : -1; }; } while(0)
|
2016-08-30 18:00:00 +02:00
|
|
|
#define StaticAssertExpr(condition, errmessage) \
|
2020-03-23 04:52:37 +01:00
|
|
|
((void) ({ StaticAssertStmt(condition, errmessage); }))
|
2020-02-03 06:48:42 +01:00
|
|
|
#define StaticAssertDecl(condition, errmessage) \
|
|
|
|
extern void static_assert_func(int static_assert_failure[(condition) ? 1 : -1])
|
2020-03-23 04:52:37 +01:00
|
|
|
#endif /* __cpp_static_assert */
|
|
|
|
#endif /* C++ */
|
2013-02-01 21:50:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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) \
|
2018-02-15 19:41:30 +01:00
|
|
|
(StaticAssertExpr(__builtin_types_compatible_p(__typeof__(varname), typename), \
|
2013-02-01 21:50:04 +01:00
|
|
|
CppAsString(varname) " does not have type " CppAsString(typename)))
|
2013-05-29 22:58:43 +02:00
|
|
|
#else /* !HAVE__BUILTIN_TYPES_COMPATIBLE_P */
|
2013-02-01 21:50:04 +01:00
|
|
|
#define AssertVariableIsOfType(varname, typename) \
|
|
|
|
StaticAssertStmt(sizeof(varname) == sizeof(typename), \
|
|
|
|
CppAsString(varname) " does not have type " CppAsString(typename))
|
|
|
|
#define AssertVariableIsOfTypeMacro(varname, typename) \
|
2018-02-15 19:41:30 +01:00
|
|
|
(StaticAssertExpr(sizeof(varname) == sizeof(typename), \
|
2013-02-01 21:50:04 +01:00
|
|
|
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 */
|
2013-02-01 21:50:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
|
|
|
* Section 7: widely useful macros
|
1996-10-31 08:10:14 +01:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
/*
|
1999-05-25 18:15:34 +02:00
|
|
|
* Max
|
1997-09-07 07:04:48 +02:00
|
|
|
* Return the maximum of two numbers.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02: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
|
1997-09-07 07:04:48 +02:00
|
|
|
* Return the minimum of two numbers.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02: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
|
1997-09-07 07:04:48 +02:00
|
|
|
* Return the absolute value of the argument.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#define Abs(x) ((x) >= 0 ? (x) : -(x))
|
1996-10-31 08:10:14 +01:00
|
|
|
|
1997-08-12 22:16:25 +02:00
|
|
|
|
2006-02-17 00:23:50 +01:00
|
|
|
/* 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
|
|
|
/*
|
2000-03-19 23:08:51 +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
|
2014-05-06 18:12:18 +02:00
|
|
|
* 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
|
2006-02-03 14:53:15 +01:00
|
|
|
* MEMSET_LOOP_LIMIT tests in configure.
|
2000-03-19 23:08:51 +01:00
|
|
|
*/
|
2002-12-16 17:22:46 +01:00
|
|
|
#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 */ \
|
2005-07-18 17:53:28 +02:00
|
|
|
void *_vstart = (void *) (start); \
|
2002-12-16 17:22:46 +01:00
|
|
|
int _val = (val); \
|
|
|
|
Size _len = (len); \
|
|
|
|
\
|
2013-10-21 03:04:52 +02:00
|
|
|
if ((((uintptr_t) _vstart) & LONG_ALIGN_MASK) == 0 && \
|
2006-02-17 00:23:50 +01:00
|
|
|
(_len & LONG_ALIGN_MASK) == 0 && \
|
2002-12-16 17:22:46 +01:00
|
|
|
_val == 0 && \
|
2006-02-03 14:53:15 +01:00
|
|
|
_len <= MEMSET_LOOP_LIMIT && \
|
|
|
|
/* \
|
|
|
|
* If MEMSET_LOOP_LIMIT == 0, optimizer should find \
|
|
|
|
* the whole "if" false at compile time. \
|
|
|
|
*/ \
|
|
|
|
MEMSET_LOOP_LIMIT != 0) \
|
2002-12-16 17:22:46 +01:00
|
|
|
{ \
|
2006-02-17 00:23:50 +01:00
|
|
|
long *_start = (long *) _vstart; \
|
|
|
|
long *_stop = (long *) ((char *) _start + _len); \
|
2002-12-16 17:22:46 +01:00
|
|
|
while (_start < _stop) \
|
|
|
|
*_start++ = 0; \
|
|
|
|
} \
|
|
|
|
else \
|
2005-07-18 17:53:28 +02:00
|
|
|
memset(_vstart, _val, _len); \
|
2002-12-16 17:22:46 +01:00
|
|
|
} 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 \
|
|
|
|
{ \
|
2006-02-17 00:23:50 +01:00
|
|
|
long *_start = (long *) (start); \
|
2002-12-16 17:22:46 +01:00
|
|
|
int _val = (val); \
|
|
|
|
Size _len = (len); \
|
|
|
|
\
|
2006-02-17 00:23:50 +01:00
|
|
|
if ((_len & LONG_ALIGN_MASK) == 0 && \
|
2002-12-16 17:22:46 +01:00
|
|
|
_val == 0 && \
|
2006-02-03 14:53:15 +01:00
|
|
|
_len <= MEMSET_LOOP_LIMIT && \
|
|
|
|
MEMSET_LOOP_LIMIT != 0) \
|
2002-12-16 17:22:46 +01:00
|
|
|
{ \
|
2006-02-17 00:23:50 +01:00
|
|
|
long *_stop = (long *) ((char *) _start + _len); \
|
2002-12-16 17:22:46 +01:00
|
|
|
while (_start < _stop) \
|
|
|
|
*_start++ = 0; \
|
|
|
|
} \
|
|
|
|
else \
|
2005-05-11 03:26:02 +02:00
|
|
|
memset(_start, _val, _len); \
|
2002-12-16 17:22:46 +01:00
|
|
|
} 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.
|
|
|
|
*/
|
2002-11-13 01:37:06 +01:00
|
|
|
#define MemSetTest(val, len) \
|
2006-02-17 00:23:50 +01:00
|
|
|
( ((len) & LONG_ALIGN_MASK) == 0 && \
|
2002-11-13 01:37:06 +01:00
|
|
|
(len) <= MEMSET_LOOP_LIMIT && \
|
2006-02-03 14:53:15 +01:00
|
|
|
MEMSET_LOOP_LIMIT != 0 && \
|
2002-11-13 01:37:06 +01:00
|
|
|
(val) == 0 )
|
|
|
|
|
|
|
|
#define MemSetLoop(start, val, len) \
|
2002-12-16 17:22:46 +01:00
|
|
|
do \
|
|
|
|
{ \
|
2006-02-17 00:23:50 +01:00
|
|
|
long * _start = (long *) (start); \
|
|
|
|
long * _stop = (long *) ((char *) _start + (Size) (len)); \
|
2002-12-16 17:22:46 +01:00
|
|
|
\
|
|
|
|
while (_start < _stop) \
|
|
|
|
*_start++ = 0; \
|
|
|
|
} while (0)
|
2000-03-19 23:08:51 +01:00
|
|
|
|
2019-11-07 17:22:52 +01:00
|
|
|
/*
|
|
|
|
* Macros for range-checking float values before converting to integer.
|
|
|
|
* We must be careful here that the boundary values are expressed exactly
|
|
|
|
* in the float domain. PG_INTnn_MIN is an exact power of 2, so it will
|
|
|
|
* be represented exactly; but PG_INTnn_MAX isn't, and might get rounded
|
|
|
|
* off, so avoid using that.
|
|
|
|
* The input must be rounded to an integer beforehand, typically with rint(),
|
|
|
|
* else we might draw the wrong conclusion about close-to-the-limit values.
|
|
|
|
* These macros will do the right thing for Inf, but not necessarily for NaN,
|
|
|
|
* so check isnan(num) first if that's a possibility.
|
|
|
|
*/
|
|
|
|
#define FLOAT4_FITS_IN_INT16(num) \
|
|
|
|
((num) >= (float4) PG_INT16_MIN && (num) < -((float4) PG_INT16_MIN))
|
|
|
|
#define FLOAT4_FITS_IN_INT32(num) \
|
|
|
|
((num) >= (float4) PG_INT32_MIN && (num) < -((float4) PG_INT32_MIN))
|
|
|
|
#define FLOAT4_FITS_IN_INT64(num) \
|
|
|
|
((num) >= (float4) PG_INT64_MIN && (num) < -((float4) PG_INT64_MIN))
|
|
|
|
#define FLOAT8_FITS_IN_INT16(num) \
|
|
|
|
((num) >= (float8) PG_INT16_MIN && (num) < -((float8) PG_INT16_MIN))
|
|
|
|
#define FLOAT8_FITS_IN_INT32(num) \
|
|
|
|
((num) >= (float8) PG_INT32_MIN && (num) < -((float8) PG_INT32_MIN))
|
|
|
|
#define FLOAT8_FITS_IN_INT64(num) \
|
|
|
|
((num) >= (float8) PG_INT64_MIN && (num) < -((float8) PG_INT64_MIN))
|
|
|
|
|
1997-09-18 16:21:02 +02:00
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/* ----------------------------------------------------------------
|
2013-02-01 21:50:04 +01:00
|
|
|
* Section 8: random stuff
|
1996-10-31 08:10:14 +01:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2020-03-28 13:01:42 +01:00
|
|
|
#ifdef HAVE_STRUCT_SOCKADDR_UN
|
|
|
|
#define HAVE_UNIX_SOCKETS 1
|
|
|
|
#endif
|
|
|
|
|
Allow btree comparison functions to return INT_MIN.
Historically we forbade datatype-specific comparison functions from
returning INT_MIN, so that it would be safe to invert the sort order
just by negating the comparison result. However, this was never
really safe for comparison functions that directly return the result
of memcmp(), strcmp(), etc, as POSIX doesn't place any such restriction
on those library functions. Buildfarm results show that at least on
recent Linux on s390x, memcmp() actually does return INT_MIN sometimes,
causing sort failures.
The agreed-on answer is to remove this restriction and fix relevant
call sites to not make such an assumption; code such as "res = -res"
should be replaced by "INVERT_COMPARE_RESULT(res)". The same is needed
in a few places that just directly negated the result of memcmp or
strcmp.
To help find places having this problem, I've also added a compile option
to nbtcompare.c that causes some of the commonly used comparators to
return INT_MIN/INT_MAX instead of their usual -1/+1. It'd likely be
a good idea to have at least one buildfarm member running with
"-DSTRESS_SORT_INT_MIN". That's far from a complete test of course,
but it should help to prevent fresh introductions of such bugs.
This is a longstanding portability hazard, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/20180928185215.ffoq2xrq5d3pafna@alap3.anarazel.de
2018-10-05 22:01:29 +02: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))
|
|
|
|
|
2018-09-01 21:27:12 +02:00
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/* msb for char */
|
2005-12-25 03:14:19 +01:00
|
|
|
#define HIGHBIT (0x80)
|
|
|
|
#define IS_HIGHBIT_SET(ch) ((unsigned char)(ch) & HIGHBIT)
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2017-11-14 19:46:54 +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'
|
|
|
|
|
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
#define STATUS_OK (0)
|
|
|
|
#define STATUS_ERROR (-1)
|
2001-10-19 00:40:52 +02:00
|
|
|
#define STATUS_EOF (-2)
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2012-03-21 22:30:14 +01:00
|
|
|
/*
|
2017-11-14 19:46:54 +01:00
|
|
|
* gettext support
|
2012-03-21 22:30:14 +01:00
|
|
|
*/
|
2017-11-14 19:46:54 +01:00
|
|
|
|
|
|
|
#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))
|
2012-03-21 22:30:14 +01:00
|
|
|
#endif
|
|
|
|
|
2017-11-14 19:46:54 +01:00
|
|
|
#define _(x) gettext(x)
|
2012-03-21 22:30:14 +01:00
|
|
|
|
2017-11-14 19:46:54 +01:00
|
|
|
/*
|
|
|
|
* 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)
|
2008-12-11 08:34:09 +01:00
|
|
|
|
|
|
|
/*
|
2017-02-06 10:33:58 +01:00
|
|
|
* To better support parallel installations of major PostgreSQL
|
2008-12-11 08:34:09 +01:00
|
|
|
* versions as well as parallel installations of major library soname
|
|
|
|
* versions, we mangle the gettext domain name by appending those
|
2015-05-20 18:44:46 +02:00
|
|
|
* version numbers. The coding rule ought to be that wherever the
|
2008-12-11 08:34:09 +01:00
|
|
|
* 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
|
2009-06-11 16:49:15 +02:00
|
|
|
#define PG_TEXTDOMAIN(domain) (domain CppAsString2(SO_MAJOR_VERSION) "-" PG_MAJORVERSION)
|
2008-12-11 08:34:09 +01:00
|
|
|
#else
|
2009-06-11 16:49:15 +02:00
|
|
|
#define PG_TEXTDOMAIN(domain) (domain "-" PG_MAJORVERSION)
|
2008-12-11 08:34:09 +01:00
|
|
|
#endif
|
|
|
|
|
2018-10-16 21:05:50 +02:00
|
|
|
/*
|
2019-03-25 09:35:29 +01:00
|
|
|
* Macro that allows to cast constness and volatile away from an expression, but doesn't
|
2018-10-16 21:05:50 +02:00
|
|
|
* allow changing the underlying type. Enforcement of the latter
|
|
|
|
* currently only works for gcc like compilers.
|
|
|
|
*
|
2018-10-25 01:47:59 +02:00
|
|
|
* Please note IT IS NOT SAFE to cast constness away if the result will ever
|
2018-10-16 21:05:50 +02:00
|
|
|
* be modified (it would be undefined behaviour). Doing so anyway can cause
|
|
|
|
* compiler misoptimizations or runtime crashes (modifying readonly memory).
|
2019-05-14 02:37:35 +02:00
|
|
|
* It is only safe to use when the result will not be modified, but API
|
2018-10-16 21:05:50 +02:00
|
|
|
* 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)
|
2018-10-25 01:47:59 +02:00
|
|
|
#define unconstify(underlying_type, expr) \
|
|
|
|
(StaticAssertExpr(__builtin_types_compatible_p(__typeof(expr), const underlying_type), \
|
2018-10-16 21:05:50 +02:00
|
|
|
"wrong cast"), \
|
2018-10-25 01:47:59 +02:00
|
|
|
(underlying_type) (expr))
|
2019-03-25 09:35:29 +01:00
|
|
|
#define unvolatize(underlying_type, expr) \
|
|
|
|
(StaticAssertExpr(__builtin_types_compatible_p(__typeof(expr), volatile underlying_type), \
|
|
|
|
"wrong cast"), \
|
|
|
|
(underlying_type) (expr))
|
2018-10-16 21:05:50 +02:00
|
|
|
#else
|
2018-10-25 01:47:59 +02:00
|
|
|
#define unconstify(underlying_type, expr) \
|
|
|
|
((underlying_type) (expr))
|
2019-03-25 09:35:29 +01:00
|
|
|
#define unvolatize(underlying_type, expr) \
|
|
|
|
((underlying_type) (expr))
|
2018-10-16 21:05:50 +02:00
|
|
|
#endif
|
2008-12-11 08:34:09 +01:00
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/* ----------------------------------------------------------------
|
2013-02-01 21:50:04 +01:00
|
|
|
* Section 9: system-specific hacks
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* This should be limited to things that absolutely have to be
|
2014-05-06 18:12:18 +02:00
|
|
|
* included in every source file. The port-specific header file
|
2001-02-10 03:31:31 +01:00
|
|
|
* is usually a better place for this sort of thing.
|
1996-10-31 08:10:14 +01:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2004-07-11 15:29:16 +02: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
|
2014-05-06 18:12:18 +02:00
|
|
|
* 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-07-11 15:29:16 +02:00
|
|
|
*/
|
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
|
2007-01-25 04:30:43 +01:00
|
|
|
#define PG_BINARY_A "ab"
|
2001-03-22 05:01:46 +01:00
|
|
|
#define PG_BINARY_R "rb"
|
|
|
|
#define PG_BINARY_W "wb"
|
2000-06-02 17:57:44 +02:00
|
|
|
#else
|
2001-03-22 05:01:46 +01:00
|
|
|
#define PG_BINARY 0
|
2007-01-25 04:30:43 +01:00
|
|
|
#define PG_BINARY_A "a"
|
2001-03-22 05:01:46 +01:00
|
|
|
#define PG_BINARY_R "r"
|
|
|
|
#define PG_BINARY_W "w"
|
2000-06-02 17:57:44 +02:00
|
|
|
#endif
|
|
|
|
|
2002-01-22 20:02:40 +01:00
|
|
|
/*
|
|
|
|
* Provide prototypes for routines not present in a particular machine's
|
2003-04-07 00:45:23 +02:00
|
|
|
* standard C library.
|
1999-01-17 04:22:52 +01:00
|
|
|
*/
|
|
|
|
|
2018-05-19 20:22:18 +02:00
|
|
|
#if defined(HAVE_FDATASYNC) && !HAVE_DECL_FDATASYNC
|
|
|
|
extern int fdatasync(int fildes);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* 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
|
2018-05-19 04:42:10 +02:00
|
|
|
extern long long strtoll(const char *str, char **endptr, int base);
|
|
|
|
#endif
|
|
|
|
|
2018-05-19 20:22:18 +02:00
|
|
|
#if defined(HAVE_STRTOULL) && !HAVE_DECL_STRTOULL
|
2018-05-19 04:42:10 +02:00
|
|
|
extern unsigned long long strtoull(const char *str, char **endptr, int base);
|
|
|
|
#endif
|
|
|
|
|
2010-05-27 09:59:48 +02:00
|
|
|
/* no special DLL markers on most ports */
|
2007-07-25 14:22:54 +02:00
|
|
|
#ifndef PGDLLIMPORT
|
2010-05-27 09:59:48 +02:00
|
|
|
#define PGDLLIMPORT
|
|
|
|
#endif
|
|
|
|
#ifndef PGDLLEXPORT
|
|
|
|
#define PGDLLEXPORT
|
2003-04-07 00:45:23 +02:00
|
|
|
#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
|
|
|
*/
|
2003-04-07 00:45:23 +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
|
Remove support for Unix systems without the POSIX signal APIs.
Remove configure's checks for HAVE_POSIX_SIGNALS, HAVE_SIGPROCMASK, and
HAVE_SIGSETJMP. These APIs are required by the Single Unix Spec v2
(POSIX 1997), which we generally consider to define our minimum required
set of Unix APIs. Moreover, no buildfarm member has reported not having
them since 2012 or before, which means that even if the code is still live
somewhere, it's untested --- and we've made plenty of signal-handling
changes of late. So just take these APIs as given and save the cycles for
configure probes for them.
However, we can't remove as much C code as I'd hoped, because the Windows
port evidently still uses the non-POSIX code paths for signal masking.
Since we're largely emulating these BSD-style APIs for Windows anyway, it
might be a good thing to switch over to POSIX-like notation and thereby
remove a few more #ifdefs. But I'm not in a position to code or test that.
In the meantime, we can at least make things a bit more transparent by
testing for WIN32 explicitly in these places.
2015-08-31 18:55:59 +02:00
|
|
|
* that case. We now support the case only on Windows.
|
2003-04-07 00:45:23 +02:00
|
|
|
*/
|
Remove support for Unix systems without the POSIX signal APIs.
Remove configure's checks for HAVE_POSIX_SIGNALS, HAVE_SIGPROCMASK, and
HAVE_SIGSETJMP. These APIs are required by the Single Unix Spec v2
(POSIX 1997), which we generally consider to define our minimum required
set of Unix APIs. Moreover, no buildfarm member has reported not having
them since 2012 or before, which means that even if the code is still live
somewhere, it's untested --- and we've made plenty of signal-handling
changes of late. So just take these APIs as given and save the cycles for
configure probes for them.
However, we can't remove as much C code as I'd hoped, because the Windows
port evidently still uses the non-POSIX code paths for signal masking.
Since we're largely emulating these BSD-style APIs for Windows anyway, it
might be a good thing to switch over to POSIX-like notation and thereby
remove a few more #ifdefs. But I'm not in a position to code or test that.
In the meantime, we can at least make things a bit more transparent by
testing for WIN32 explicitly in these places.
2015-08-31 18:55:59 +02:00
|
|
|
#ifdef WIN32
|
2003-08-04 02:43:34 +02:00
|
|
|
#define sigjmp_buf jmp_buf
|
|
|
|
#define sigsetjmp(x,y) setjmp(x)
|
|
|
|
#define siglongjmp longjmp
|
2003-04-07 00:45:23 +02:00
|
|
|
#endif
|
|
|
|
|
2003-12-20 18:31:21 +01:00
|
|
|
/* EXEC_BACKEND defines */
|
|
|
|
#ifdef EXEC_BACKEND
|
|
|
|
#define NON_EXEC_STATIC
|
|
|
|
#else
|
|
|
|
#define NON_EXEC_STATIC static
|
|
|
|
#endif
|
|
|
|
|
2003-05-15 18:35:30 +02:00
|
|
|
/* /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 */
|