// Code generated by modernc.org/undup from the per-target sqlite_*.go files; DO NOT EDIT. //go:build (freebsd && 386) || (freebsd && amd64) || (freebsd && arm) || (freebsd && arm64) || (linux && 386) || (linux && amd64) || (linux && arm) || (linux && arm64) || (linux && loong64) || (linux && ppc64le) || (linux && riscv64) || (linux && s390x) || (netbsd && amd64) || (openbsd && amd64) || (openbsd && arm64) package sqlite3 import ( "unsafe" "modernc.org/libc" ) const AT_FDCWD = -100 const HAVE_FULLFSYNC = 0 const INT_FAST16_MAX = 2147483647 const INT_FAST16_MIN = -2147483648 const RTLD_GLOBAL = 256 type Tfsblkcnt_t = uint64 type Tfsfilcnt_t = uint64 type Tint_fast16_t = int32 type Tlocale_t = uintptr type Tuint_fast16_t = uint32 const UINT_FAST16_MAX = 4294967295 // C documentation // // /* // ** If the following global variable points to a string which is the // ** name of a directory, then that directory will be used to store // ** temporary files. // ** // ** See also the "PRAGMA temp_store_directory" SQL command. // */ var Xsqlite3_temp_directory uintptr /* ** Make sure we can call this stuff from C++. */ /* ** Facilitate override of interface linkage and calling conventions. ** Be aware that these macros may not be used within this particular ** translation of the amalgamation and its associated header file. ** ** The SQLITE_EXTERN and SQLITE_API macros are used to instruct the ** compiler that the target identifier should have external linkage. ** ** The SQLITE_CDECL macro is used to set the calling convention for ** public functions that accept a variable number of arguments. ** ** The SQLITE_APICALL macro is used to set the calling convention for ** public functions that accept a fixed number of arguments. ** ** The SQLITE_STDCALL macro is no longer used and is now deprecated. ** ** The SQLITE_CALLBACK macro is used to set the calling convention for ** function pointers. ** ** The SQLITE_SYSAPI macro is used to set the calling convention for ** functions provided by the operating system. ** ** Currently, the SQLITE_CDECL, SQLITE_APICALL, SQLITE_CALLBACK, and ** SQLITE_SYSAPI macros are used only when building for environments ** that require non-default calling conventions. */ /* ** These no-op macros are used in front of interfaces to mark those ** interfaces as either deprecated or experimental. New applications ** should not use deprecated interfaces - they are supported for backwards ** compatibility only. Application writers should be aware that ** experimental interfaces are subject to change in point releases. ** ** These macros used to resolve to various kinds of compiler magic that ** would generate warning messages when they were used. But that ** compiler magic ended up generating such a flurry of bug reports ** that we have taken it all out and gone back to using simple ** noop macros. */ /* ** Ensure these symbols were not defined by some previous header file. */ /* ** CAPI3REF: Compile-Time Library Version Numbers ** ** ^(The [SQLITE_VERSION] C preprocessor macro in the sqlite3.h header ** evaluates to a string literal that is the SQLite version in the ** format "X.Y.Z" where X is the major version number (always 3 for ** SQLite3) and Y is the minor version number and Z is the release number.)^ ** ^(The [SQLITE_VERSION_NUMBER] C preprocessor macro resolves to an integer ** with the value (X*1000000 + Y*1000 + Z) where X, Y, and Z are the same ** numbers used in [SQLITE_VERSION].)^ ** The SQLITE_VERSION_NUMBER for any given release of SQLite will also ** be larger than the release from which it is derived. Either Y will ** be held constant and Z will be incremented or else Y will be incremented ** and Z will be reset to zero. ** ** Since [version 3.6.18] ([dateof:3.6.18]), ** SQLite source code has been stored in the ** Fossil configuration management ** system. ^The SQLITE_SOURCE_ID macro evaluates to ** a string which identifies a particular check-in of SQLite ** within its configuration management system. ^The SQLITE_SOURCE_ID ** string contains the date and time of the check-in (UTC) and a SHA1 ** or SHA3-256 hash of the entire source tree. If the source code has ** been edited in any way since it was last checked in, then the last ** four hexadecimal digits of the hash may be modified. ** ** See also: [sqlite3_libversion()], ** [sqlite3_libversion_number()], [sqlite3_sourceid()], ** [sqlite_version()] and [sqlite_source_id()]. */ // C documentation // // /* // ** Return the ON CONFLICT resolution mode in effect for the virtual // ** table update operation currently in progress. // ** // ** The results of this routine are undefined unless it is called from // ** within an xUpdate method. // */ func Xsqlite3_vtab_on_conflict(tls *libc.TLS, db uintptr) (r int32) { return libc.Int32FromUint8(_aMap[libc.Int32FromUint8((*Tsqlite3)(unsafe.Pointer(db)).FvtabOnConflict)-int32(1)]) } const _POSIX_CHOWN_RESTRICTED = 1 const _POSIX_JOB_CONTROL = 1 const _POSIX_NO_TRUNC = 1 const _POSIX_REGEXP = 1 const _POSIX_SHELL = 1 const __ELF__ = 1 const __unix__ = 1 // C documentation // // /* // ** Close a file. Make sure the lock has been released before closing. // */ func _dotlockClose(tls *libc.TLS, id uintptr) (r int32) { var pFile uintptr _ = pFile pFile = id _dotlockUnlock(tls, id, NO_LOCK) Xsqlite3_free(tls, (*TunixFile)(unsafe.Pointer(pFile)).FlockingContext) return _closeUnixFile(tls, id) } /****************** End of the dot-file lock implementation ******************* ******************************************************************************/ /****************************************************************************** ************************** Begin flock Locking ******************************** ** ** Use the flock() system call to do file locking. ** ** flock() locking is like dot-file locking in that the various ** fine-grain locking levels supported by SQLite are collapsed into ** a single exclusive lock. In other words, SHARED, RESERVED, and ** PENDING locks are the same thing as an EXCLUSIVE lock. SQLite ** still works when you do this, but concurrency is reduced since ** only a single process can be reading the database at a time. ** ** Omit this section if SQLITE_ENABLE_LOCKING_STYLE is turned off */ /******************* End of the flock lock implementation ********************* ******************************************************************************/ /****************************************************************************** ************************ Begin Named Semaphore Locking ************************ ** ** Named semaphore locking is only supported on VxWorks. ** ** Semaphore locking is like dot-lock and flock in that it really only ** supports EXCLUSIVE locking. Only a single process can read or write ** the database file at a time. This reduces potential concurrency, but ** makes the lock implementation much easier. */ /* ** Named semaphore locking is only available on VxWorks. ** *************** End of the named semaphore lock implementation **************** ******************************************************************************/ /****************************************************************************** *************************** Begin AFP Locking ********************************* ** ** AFP is the Apple Filing Protocol. AFP is a network filesystem found ** on Apple Macintosh computers - both OS9 and OSX. ** ** Third-party implementations of AFP are available. But this code here ** only works on OSX. */ /* ** The code above is the AFP lock implementation. The code is specific ** to MacOSX and does not work on other unix platforms. No alternative ** is available. If you don't compile for a mac, then the "unix-afp" ** VFS is not available. ** ********************* End of the AFP lock implementation ********************** ******************************************************************************/ /****************************************************************************** *************************** Begin NFS Locking ********************************/ /* ** The code above is the NFS lock implementation. The code is specific ** to MacOSX and does not work on other unix platforms. No alternative ** is available. ** ********************* End of the NFS lock implementation ********************** ******************************************************************************/ /****************************************************************************** **************** Non-locking sqlite3_file methods ***************************** ** ** The next division contains implementations for all methods of the ** sqlite3_file object other than the locking methods. The locking ** methods were defined in divisions above (one locking method per ** division). Those methods that are common to all locking modes ** are gather together into this division. */ // C documentation // // /* // ** The fsync() system call does not work as advertised on many // ** unix systems. The following procedure is an attempt to make // ** it work better. // ** // ** The SQLITE_NO_SYNC macro disables all fsync()s. This is useful // ** for testing when we want to run through the test suite quickly. // ** You are strongly advised *not* to deploy with SQLITE_NO_SYNC // ** enabled, however, since with SQLITE_NO_SYNC enabled, an OS crash // ** or power failure will likely corrupt the database file. // ** // ** SQLite sets the dataOnly flag if the size of the file is unchanged. // ** The idea behind dataOnly is that it should only write the file content // ** to disk, not the inode. We only set dataOnly if the file size is // ** unchanged since the file size is part of the inode. However, // ** Ted Ts'o tells us that fdatasync() will also write the inode if the // ** file size has changed. The only real difference between fdatasync() // ** and fsync(), Ted tells us, is that fdatasync() will not flush the // ** inode if the mtime or owner or other inode attributes have changed. // ** We only care about the file size, not the other file attributes, so // ** as far as SQLite is concerned, an fdatasync() is always adequate. // ** So, we always use fdatasync() if it is available, regardless of // ** the value of the dataOnly flag. // */ func _full_fsync(tls *libc.TLS, fd int32, fullSync int32, dataOnly int32) (r int32) { var rc int32 _ = rc /* The following "ifdef/elif/else/" block has the same structure as ** the one below. It is replicated here solely to avoid cluttering ** up the real code with the UNUSED_PARAMETER() macros. */ _ = fullSync _ = dataOnly /* Record the number of times that we do a normal fsync() and ** FULLSYNC. This is used during testing to verify that this procedure ** gets called with the correct arguments. */ /* If we compiled with the SQLITE_NO_SYNC flag, then syncing is a ** no-op. But go ahead and call fstat() to validate the file ** descriptor as we need a method to provoke a failure during ** coverage testing. */ rc = libc.Xfsync(tls, fd) if libc.Bool(OS_VXWORKS != 0) && rc != -int32(1) { rc = 0 } return rc } func init() { p := unsafe.Pointer(&_dotlockIoFinder) *(*uintptr)(unsafe.Add(p, 0)) = __ccgo_fp(_dotlockIoFinderImpl) } /* ** The proxy locking method is a "super-method" in the sense that it ** opens secondary file descriptors for the conch and lock files and ** it uses proxy, dot-file, AFP, and flock() locking methods on those ** secondary files. For this reason, the division that implements ** proxy locking is located much further down in the file. But we need ** to go ahead and define the sqlite3_io_methods and finder function ** for proxy locking here. So we forward declare the I/O methods. */ /* nfs lockd on OSX 10.3+ doesn't clear write locks when a read lock is set */ type locale_t = Tlocale_t const math_errhandling = 2 type timer_t = Ttimer_t