Drop support for the SQLITE_OMIT_MEMORY_ALLOCATION compile-time option. (CVS 4529)

FossilOrigin-Name: b57c89fed0b74c2e8fb68ccfdf5e5e7d4b2603a1

manifest

@@ -1,5 +1,5 @@
-C Reset\sthe\swriter-thread\shalt\scriteria\safter\shalting\sthe\sthread.\s(CVS\s4528)
-D 2007-11-05T17:01:08
+C Drop\ssupport\sfor\sthe\sSQLITE_OMIT_MEMORY_ALLOCATION\scompile-time\soption.\s(CVS\s4529)
+D 2007-11-05T17:54:17
 F Makefile.in 30c7e3ba426ddb253b8ef037d1873425da6009a8
 F Makefile.linux-gcc 65241babba6faf1152bf86574477baab19190499
 F README 9c4e2d6706bdcc3efdd773ce752a8cdab4f90028
@@ -102,8 +102,8 @@ F src/loadext.c 124e566563d1c03e68e1396cb44df9870612c6e9
 F src/main.c 994a6b6914d91dc6dea5012667ec0a52e74d3bca
 F src/malloc.c 60e392a4c12c839517f9b0db7b995f825444fb35
 F src/md5.c c5fdfa5c2593eaee2e32a5ce6c6927c986eaf217
-F src/mem1.c cacb202bc379da10d69aa66d497c0ea7bd9cd8a5
-F src/mem2.c 3f669b5e20975a5a2ca392aca891cd686e22b097
+F src/mem1.c ad348eedd829528e66f4a5aead464d88e6b08d69
+F src/mem2.c 2a1da2e8debcfd0097188470f04573107a018116
 F src/mem3.c df13c608e8dfb54f62e3448eb126e760aecbacf1
 F src/mutex.c 3259f62c2429967aee6dc112117a6d2f499ef061
 F src/mutex.h 079fa6fe9da18ceb89e79012c010594c6672addb
@@ -131,7 +131,7 @@ F src/random.c 4a22746501bf36b0a088c66e38dde5daba6a35da
 F src/select.c 4706a6115da1bdc09a2be5991168a6cc2c0df267
 F src/server.c 087b92a39d883e3fa113cae259d64e4c7438bc96
 F src/shell.c 0b9dd90afc34f28b8786638155d32f6248d0bf0a
-F src/sqlite.h.in 430a26215c164a2d4236dcbce4730a704b455271
+F src/sqlite.h.in 3844177d389d58bd4a8be4ee81eefb01a084ed72
 F src/sqlite3ext.h a93f59cdee3638dc0c9c086f80df743a4e68c3cb
 F src/sqliteInt.h 7fd5cfa357d7aefe22cd2bcdfabcca4e7d5ab5b2
 F src/sqliteLimit.h 15ffe2116746c27ace2b428a26a4fcd6dba6fa65
@@ -584,7 +584,7 @@ F www/tclsqlite.tcl 8be95ee6dba05eabcd27a9d91331c803f2ce2130
 F www/vdbe.tcl 87a31ace769f20d3627a64fa1fade7fed47b90d0
 F www/version3.tcl 890248cf7b70e60c383b0e84d77d5132b3ead42b
 F www/whentouse.tcl fc46eae081251c3c181bd79c5faef8195d7991a5
-P b752906e708e1c8c76084152f5829e16e8988ef2
-R 7f1455a4cfebc5f5c43e5e1e4ec5f996
-U danielk1977
-Z e5e92eeb58930447253626b7e5820cf1
+P ecbff972a1f5c7d846c322c435fa73584655b7f0
+R 4a6faeb1d5909fa4fd0f66b7cab8ebd0
+U drh
+Z c84b000500150d084eda9369c9fa3fc9

manifest.uuid

@@ -1 +1 @@
-ecbff972a1f5c7d846c322c435fa73584655b7f0
+b57c89fed0b74c2e8fb68ccfdf5e5e7d4b2603a1

src/mem1.c

@@ -12,7 +12,7 @@
 ** This file contains the C functions that implement a memory
 ** allocation subsystem for use by SQLite.  
 **
-** $Id: mem1.c,v 1.12 2007/10/19 17:47:25 drh Exp $
+** $Id: mem1.c,v 1.13 2007/11/05 17:54:17 drh Exp $
 */
 
 /*
@@ -20,8 +20,7 @@
 ** used when no other memory allocator is specified using compile-time
 ** macros.
 */
-#if !defined(SQLITE_MEMDEBUG) && !defined(SQLITE_OMIT_MEMORY_ALLOCATION) \
-      && !defined(SQLITE_MEMORY_SIZE)
+#if !defined(SQLITE_MEMDEBUG) && !defined(SQLITE_MEMORY_SIZE)
 
 /*
 ** We will eventually construct multiple memory allocation subsystems

src/mem2.c

@@ -12,7 +12,7 @@
 ** This file contains the C functions that implement a memory
 ** allocation subsystem for use by SQLite.  
 **
-** $Id: mem2.c,v 1.16 2007/10/19 17:47:25 drh Exp $
+** $Id: mem2.c,v 1.17 2007/11/05 17:54:17 drh Exp $
 */
 
 /*
@@ -20,8 +20,7 @@
 ** SQLITE_MEMDEBUG macro is defined and SQLITE_OMIT_MEMORY_ALLOCATION
 ** is not defined.
 */
-#if defined(SQLITE_MEMDEBUG) && !defined(SQLITE_OMIT_MEMORY_ALLOCATION) \
-           && !defined(SQLITE_MEMORY_SIZE)
+#if defined(SQLITE_MEMDEBUG) && !defined(SQLITE_MEMORY_SIZE)
 
 /*
 ** We will eventually construct multiple memory allocation subsystems

src/sqlite.h.in

@@ -30,7 +30,7 @@
 ** the version number) and changes its name to "sqlite3.h" as
 ** part of the build process.
 **
-** @(#) $Id: sqlite.h.in,v 1.268 2007/10/27 16:25:16 drh Exp $
+** @(#) $Id: sqlite.h.in,v 1.269 2007/11/05 17:54:17 drh Exp $
 */
 #ifndef _SQLITE3_H_
 #define _SQLITE3_H_
@@ -1131,29 +1131,23 @@ char *sqlite3_snprintf(int,char*,const char*, ...);
 **
 ** The SQLite core uses these three routines for all of its own
 ** internal memory allocation needs. (See the exception below.)
+**
 ** The default implementation
 ** of the memory allocation subsystem uses the malloc(), realloc()
 ** and free() provided by the standard C library.  However, if 
 ** SQLite is compiled with the following C preprocessor macro
 **
-** <blockquote> SQLITE_OMIT_MEMORY_ALLOCATION </blockquote>
+** <blockquote> SQLITE_MEMORY_SIZE=<i>NNN</i> </blockquote>
 **
-** then no implementation is provided for these routines by
-** SQLite.  The application that links against SQLite is
-** expected to provide its own implementation.  If the application
-** does provide its own implementation for these routines, then
-** it must also provide an implementations for
-** [sqlite3_memory_alarm()], [sqlite3_memory_used()], and
-** [sqlite3_memory_highwater()].  The alternative implementations
-** for these last three routines need not actually work, but
-** stub functions at least are needed to statisfy the linker.
-** SQLite never calls [sqlite3_memory_highwater()] itself, but
-** the symbol is included in a table as part of the
-** [sqlite3_load_extension()] interface.  The
-** [sqlite3_memory_alarm()] and [sqlite3_memory_used()] interfaces
-** are called by [sqlite3_soft_heap_limit()] and working implementations
-** of both routines must be provided if [sqlite3_soft_heap_limit()]
-** is to operate correctly.
+** where <i>NNN</i> is an integer, then SQLite create a static
+** array of at least <i>NNN</i> bytes in size and use that array
+** for all of its dynamic memory allocation needs.
+**
+** In SQLite version 3.5.0 and 3.5.1, it was possible to define
+** the SQLITE_OMIT_MEMORY_ALLOCATION which would cause the built-in
+** implementation of these routines to be omitted.  That capability
+** is no longer provided.  Only built-in memory allocators can be
+** used.
 **
 ** <b>Exception:</b> The windows OS interface layer calls
 ** the system malloc() and free() directly when converting
@@ -1181,54 +1175,13 @@ void sqlite3_free(void*);
 ** memory.  The highwater mark is reset if the argument is
 ** true.
 **
-** The implementation of these routines in the SQLite core
-** is omitted if the application is compiled with the
-** SQLITE_OMIT_MEMORY_ALLOCATION macro defined.  In that case,
-** the application that links SQLite must provide its own
-** alternative implementation.  See the documentation on
-** [sqlite3_malloc()] for additional information.
+** The value returned may or may not include allocation
+** overhead, depending on which built-in memory allocator
+** implementation is used.
 */
 sqlite3_int64 sqlite3_memory_used(void);
 sqlite3_int64 sqlite3_memory_highwater(int resetFlag);
 
-/*
-** CAPI3REF: Memory Allocation Alarms
-**
-** The [sqlite3_memory_alarm] routine is used to register
-** a callback on memory allocation events.
-**
-** This routine registers or clears a callbacks that fires when
-** the amount of memory allocated exceeds iThreshold.  Only
-** a single callback can be registered at a time.  Each call
-** to [sqlite3_memory_alarm()] overwrites the previous callback.
-** The callback is disabled by setting xCallback to a NULL
-** pointer.
-** 
-** The parameters to the callback are the pArg value, the 
-** amount of memory currently in use, and the size of the
-** allocation that provoked the callback.  The callback will
-** presumably invoke [sqlite3_free()] to free up memory space.
-** The callback may invoke [sqlite3_malloc()] or [sqlite3_realloc()]
-** but if it does, no additional callbacks will be invoked by
-** the recursive calls.
-**
-** The [sqlite3_soft_heap_limit()] interface works by registering
-** a memory alarm at the soft heap limit and invoking 
-** [sqlite3_release_memory()] in the alarm callback.  Application
-** programs should not attempt to use the [sqlite3_memory_alarm()]
-** interface because doing so will interfere with the
-** [sqlite3_soft_heap_limit()] module.  This interface is exposed
-** only so that applications can provide their own
-** alternative implementation when the SQLite core is
-** compiled with SQLITE_OMIT_MEMORY_ALLOCATION.
-*/
-int sqlite3_memory_alarm(
-  void(*xCallback)(void *pArg, sqlite3_int64 used, int N),
-  void *pArg,
-  sqlite3_int64 iThreshold
-);
-
-
 /*
 ** CAPI3REF: Compile-Time Authorization Callbacks
 ***
@@ -2324,6 +2277,7 @@ int sqlite3_expired(sqlite3_stmt*);
 int sqlite3_transfer_bindings(sqlite3_stmt*, sqlite3_stmt*);
 int sqlite3_global_recover(void);
 void sqlite3_thread_cleanup(void);
+int sqlite3_memory_alarm(void(*)(void*,sqlite3_int64,int),void*,sqlite3_int64);
 
 /*
 ** CAPI3REF: Obtaining SQL Function Parameter Values
@@ -2829,12 +2783,6 @@ int sqlite3_release_memory(int);
 ** continue without error or notification.  This is why the limit is 
 ** called a "soft" limit.  It is advisory only.
 **
-** The soft heap limit is implemented using the [sqlite3_memory_alarm()]
-** interface.  Only a single memory alarm is available in the default
-** implementation.  This means that if the application also uses the
-** memory alarm interface it will interfere with the operation of the
-** soft heap limit and undefined behavior will result.  
-**
 ** Prior to SQLite version 3.5.0, this routine only constrained the memory
 ** allocated by a single thread - the same thread in which this routine
 ** runs.  Beginning with SQLite version 3.5.0, the soft heap limit is