CopyHandler

Clone
ixen <ixen@copyhandler.com>
committed
c2ddd0c
on 28 Mar 19
Enabled enforcing type conversion rules (CH-338).
ext/sqlite3/sqlite3.h (+10 -3)
104 104 ** with the value (X*1000000 + Y*1000 + Z) where X, Y, and Z are the same
105 105 ** numbers used in [SQLITE_VERSION].)^
106 106 ** The SQLITE_VERSION_NUMBER for any given release of SQLite will also
107 107 ** be larger than the release from which it is derived.  Either Y will
108 108 ** be held constant and Z will be incremented or else Y will be incremented
109 109 ** and Z will be reset to zero.
110 110 **
111 111 ** Since [version 3.6.18] ([dateof:3.6.18]),
112 112 ** SQLite source code has been stored in the
113 113 ** <a href="http://www.fossil-scm.org/">Fossil configuration management
114 114 ** system</a>.  ^The SQLITE_SOURCE_ID macro evaluates to
115 115 ** a string which identifies a particular check-in of SQLite
116 116 ** within its configuration management system.  ^The SQLITE_SOURCE_ID
117 117 ** string contains the date and time of the check-in (UTC) and an SHA1
118 118 ** hash of the entire source tree.
119 119 **
120 120 ** See also: [sqlite3_libversion()],
121 121 ** [sqlite3_libversion_number()], [sqlite3_sourceid()],
122 122 ** [sqlite_version()] and [sqlite_source_id()].
123 123 */
124   #define SQLITE_VERSION        "3.15.0"
125   #define SQLITE_VERSION_NUMBER 3015000
126   #define SQLITE_SOURCE_ID      "2016-10-14 10:20:30 707875582fcba352b4906a595ad89198d84711d8"
  124 #define SQLITE_VERSION        "3.15.1"
  125 #define SQLITE_VERSION_NUMBER 3015001
  126 #define SQLITE_SOURCE_ID      "2016-11-04 12:08:49 1136863c76576110e710dd5d69ab6bf347c65e36"
127 127
128 128 /*
129 129 ** CAPI3REF: Run-Time Library Version Numbers
130 130 ** KEYWORDS: sqlite3_version, sqlite3_sourceid
131 131 **
132 132 ** These interfaces provide the same information as the [SQLITE_VERSION],
133 133 ** [SQLITE_VERSION_NUMBER], and [SQLITE_SOURCE_ID] C preprocessor macros
134 134 ** but are associated with the library instead of the header file.  ^(Cautious
135 135 ** programmers might include assert() statements in their application to
136 136 ** verify that values returned by these interfaces match the macros in
137 137 ** the header, and thus ensure that the application is
138 138 ** compiled with matching library and header files.
139 139 **
140 140 ** <blockquote><pre>
141 141 ** assert( sqlite3_libversion_number()==SQLITE_VERSION_NUMBER );
142 142 ** assert( strcmp(sqlite3_sourceid(),SQLITE_SOURCE_ID)==0 );
143 143 ** assert( strcmp(sqlite3_libversion(),SQLITE_VERSION)==0 );
144 144 ** </pre></blockquote>)^
145 145 **
146 146 ** ^The sqlite3_version[] string constant contains the text of [SQLITE_VERSION]
 
961 961 ** is an advisory maximum number of bytes in the file to memory map.  The
962 962 ** pointer is overwritten with the old value.  The limit is not changed if
963 963 ** the value originally pointed to is negative, and so the current limit
964 964 ** can be queried by passing in a pointer to a negative number.  This
965 965 ** file-control is used internally to implement [PRAGMA mmap_size].
966 966 **
967 967 ** <li>[[SQLITE_FCNTL_TRACE]]
968 968 ** The [SQLITE_FCNTL_TRACE] file control provides advisory information
969 969 ** to the VFS about what the higher layers of the SQLite stack are doing.
970 970 ** This file control is used by some VFS activity tracing [shims].
971 971 ** The argument is a zero-terminated string.  Higher layers in the
972 972 ** SQLite stack may generate instances of this file control if
973 973 ** the [SQLITE_USE_FCNTL_TRACE] compile-time option is enabled.
974 974 **
975 975 ** <li>[[SQLITE_FCNTL_HAS_MOVED]]
976 976 ** The [SQLITE_FCNTL_HAS_MOVED] file control interprets its argument as a
977 977 ** pointer to an integer and it writes a boolean into that integer depending
978 978 ** on whether or not the file has been renamed, moved, or deleted since it
979 979 ** was first opened.
980 980 **
  981 ** <li>[[SQLITE_FCNTL_WIN32_GET_HANDLE]]
  982 ** The [SQLITE_FCNTL_WIN32_GET_HANDLE] opcode can be used to obtain the
  983 ** underlying native file handle associated with a file handle.  This file
  984 ** control interprets its argument as a pointer to a native file handle and
  985 ** writes the resulting value there.
  986 **
981 987 ** <li>[[SQLITE_FCNTL_WIN32_SET_HANDLE]]
982 988 ** The [SQLITE_FCNTL_WIN32_SET_HANDLE] opcode is used for debugging.  This
983 989 ** opcode causes the xFileControl method to swap the file handle with the one
984 990 ** pointed to by the pArg argument.  This capability is used during testing
985 991 ** and only needs to be supported when SQLITE_TEST is defined.
986 992 **
987 993 ** <li>[[SQLITE_FCNTL_WAL_BLOCK]]
988 994 ** The [SQLITE_FCNTL_WAL_BLOCK] is a signal to the VFS layer that it might
989 995 ** be advantageous to block on the next WAL lock if the lock is not immediately
990 996 ** available.  The WAL subsystem issues this signal during rare
991 997 ** circumstances in order to fix a problem with priority inversion.
992 998 ** Applications should <em>not</em> use this file-control.
993 999 **
994 1000 ** <li>[[SQLITE_FCNTL_ZIPVFS]]
995 1001 ** The [SQLITE_FCNTL_ZIPVFS] opcode is implemented by zipvfs only. All other
996 1002 ** VFS should return SQLITE_NOTFOUND for this opcode.
997 1003 **
998 1004 ** <li>[[SQLITE_FCNTL_RBU]]
999 1005 ** The [SQLITE_FCNTL_RBU] opcode is implemented by the special VFS used by
1000 1006 ** the RBU extension only.  All other VFS should return SQLITE_NOTFOUND for
 
1011 1017 #define SQLITE_FCNTL_SYNC_OMITTED            8
1012 1018 #define SQLITE_FCNTL_WIN32_AV_RETRY          9
1013 1019 #define SQLITE_FCNTL_PERSIST_WAL            10
1014 1020 #define SQLITE_FCNTL_OVERWRITE              11
1015 1021 #define SQLITE_FCNTL_VFSNAME                12
1016 1022 #define SQLITE_FCNTL_POWERSAFE_OVERWRITE    13
1017 1023 #define SQLITE_FCNTL_PRAGMA                 14
1018 1024 #define SQLITE_FCNTL_BUSYHANDLER            15
1019 1025 #define SQLITE_FCNTL_TEMPFILENAME           16
1020 1026 #define SQLITE_FCNTL_MMAP_SIZE              18
1021 1027 #define SQLITE_FCNTL_TRACE                  19
1022 1028 #define SQLITE_FCNTL_HAS_MOVED              20
1023 1029 #define SQLITE_FCNTL_SYNC                   21
1024 1030 #define SQLITE_FCNTL_COMMIT_PHASETWO        22
1025 1031 #define SQLITE_FCNTL_WIN32_SET_HANDLE       23
1026 1032 #define SQLITE_FCNTL_WAL_BLOCK              24
1027 1033 #define SQLITE_FCNTL_ZIPVFS                 25
1028 1034 #define SQLITE_FCNTL_RBU                    26
1029 1035 #define SQLITE_FCNTL_VFS_POINTER            27
1030 1036 #define SQLITE_FCNTL_JOURNAL_POINTER        28
  1037 #define SQLITE_FCNTL_WIN32_GET_HANDLE       29
1031 1038
1032 1039 /* deprecated names */
1033 1040 #define SQLITE_GET_LOCKPROXYFILE      SQLITE_FCNTL_GET_LOCKPROXYFILE
1034 1041 #define SQLITE_SET_LOCKPROXYFILE      SQLITE_FCNTL_SET_LOCKPROXYFILE
1035 1042 #define SQLITE_LAST_ERRNO             SQLITE_FCNTL_LAST_ERRNO
1036 1043
1037 1044
1038 1045 /*
1039 1046 ** CAPI3REF: Mutex Handle
1040 1047 **
1041 1048 ** The mutex module within SQLite defines [sqlite3_mutex] to be an
1042 1049 ** abstract type for a mutex object.  The SQLite core never looks
1043 1050 ** at the internal representation of an [sqlite3_mutex].  It only
1044 1051 ** deals with pointers to the [sqlite3_mutex] object.
1045 1052 **
1046 1053 ** Mutexes are created using [sqlite3_mutex_alloc()].
1047 1054 */
1048 1055 typedef struct sqlite3_mutex sqlite3_mutex;
1049 1056
1050 1057 /*