-C Removed\sa\sfew\scompiler\swarnings\sunder\sMSVC.\s(CVS\s6825)
-D 2009-06-26T16:32:13
+C Remove\sincorrect\sNEVER()\smacros\sfrom\smalloc.c.\s\sThe\sallocations\scan\sbe\nexceeded\susing\ssqlite3_malloc()\sand\ssqlite3_realloc().\s(CVS\s6826)
+D 2009-06-26T18:35:17
F Makefile.arm-wince-mingw32ce-gcc fcd5e9cd67fe88836360bb4f9ef4cb7f8e2fb5a0
F Makefile.in 8b8fb7823264331210cddf103831816c286ba446
F Makefile.linux-gcc d53183f4aa6a9192d249731c90dbdffbd2c68654
F src/legacy.c 9a56cf126ceee332b56061bf16bd0fb4ff9e26c0
F src/loadext.c 0e88a335665db0b2fb4cece3e49dcb65d832635a
F src/main.c 9f6d91815233b517c1bdf16fd8fa838d10d2c015
-F src/malloc.c 7b3b6423f5b355e5d649b91e16ef252d610bcf19
+F src/malloc.c 55c4e997480b89833e693832298b5a7cfd9df9aa
F src/mem0.c f2f84062d1f35814d6535c9f9e33de3bfb3b132c
F src/mem1.c e6d5c23941288df8191b8a98c28e3f57771e2270
F src/mem2.c d02bd6a5b34f2d59012a852615621939d9c09548
F tool/speedtest8.c 2902c46588c40b55661e471d7a86e4dd71a18224
F tool/speedtest8inst1.c 293327bc76823f473684d589a8160bde1f52c14e
F tool/vdbe-compress.tcl 672f81d693a03f80f5ae60bfefacd8a349e76746
-P 96729b2d499f029bfaec6648a592e8ec697d9521
-R fc4b7c1a6225b0393bf8a20671e309c4
-U shane
-Z 4b1a0e3f6dd4fd54dd886da2d6eabcca
+P f01a9fc375d77c67602a9f6be6a674beb516233f
+R 2e353673e103372172748404661066b9
+U drh
+Z c395fb0e87a2bccde31a68bf5019fc25
**
** Memory allocation functions used throughout sqlite.
**
-** $Id: malloc.c,v 1.62 2009/05/03 20:23:54 drh Exp $
+** $Id: malloc.c,v 1.63 2009/06/26 18:35:17 drh Exp $
*/
#include "sqliteInt.h"
#include <stdarg.h>
*/
void *sqlite3Malloc(int n){
void *p;
- if( n<=0 || NEVER(n>=0x7fffff00) ){
- /* The NEVER(n>=0x7fffff00) term is added out of paranoia. We want to make
- ** absolutely sure that there is nothing within SQLite that can cause a
- ** memory allocation of a number of bytes which is near the maximum signed
- ** integer value and thus cause an integer overflow inside of the xMalloc()
- ** implementation. The n>=0x7fffff00 gives us 255 bytes of headroom. The
- ** test should never be true because SQLITE_MAX_LENGTH should be much
- ** less than 0x7fffff00 and it should catch large memory allocations
- ** before they reach this point. */
+ if( n<=0 || n>=0x7fffff00 ){
+ /* A memory allocation of a number of bytes which is near the maximum
+ ** signed integer value might cause an integer overflow inside of the
+ ** xMalloc(). Hence we limit the maximum size to 0x7fffff00, giving
+ ** 255 bytes of overhead. SQLite itself will never use anything near
+ ** this amount. The only way to reach the limit is with sqlite3_malloc() */
p = 0;
}else if( sqlite3GlobalConfig.bMemstat ){
sqlite3_mutex_enter(mem0.mutex);
if( pOld==0 ){
return sqlite3Malloc(nBytes);
}
- if( nBytes<=0 || NEVER(nBytes>=0x7fffff00) ){
- /* The NEVER(...) term is explained in comments on sqlite3Malloc() */
+ if( nBytes<=0 || nBytes>=0x7fffff00 ){
+ /* The 0x7ffff00 limit term is explained in comments on sqlite3Malloc() */
sqlite3_free(pOld);
return 0;
}