Maven/vendor/modernc.org/sqlite/lib/sqlite_g_000000000001fffc.go

// 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
** <a href="http://fossil-scm.org/">Fossil configuration management
** system</a>.  ^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