In our C dialect supporting CHERI capabilities (http://cheri-cpu.org)
as unforgable fat pointers, we require that all conversions of integers
to pointers be made via (u)intptr_t. This allows macros that take
either pointers or integers to preserve pointer integrity (e.g. long
does not in our system) and ensures that the programmer knows they are
converting an integer to a pointer. SQLite contains a an implementation
of SQLITE_INT_TO_PTR/SQLITE_PTR_TO_INT that does this, but due to the
ifdef order it isn't used without changes.
We carry the following patch to our tree:
diff --git a/contrib/sqlite3/sqlite3.c b/contrib/sqlite3/sqlite3.c
index 1344938873b..2847deed917 100644
--- a/contrib/sqlite3/sqlite3.c
+++ b/contrib/sqlite3/sqlite3.c
@@ -8335,15 +8335,15 @@ struct sqlite3_rtree_query_info {
** So we have to define the macros in different ways depending on the
** compiler.
*/
-#if defined(__PTRDIFF_TYPE__) /* This case should work for GCC */
+#if defined(HAVE_STDINT_H) /* Use this case if we have ANSI headers */
+# define SQLITE_INT_TO_PTR(X) ((void*)(intptr_t)(X))
+# define SQLITE_PTR_TO_INT(X) ((int)(intptr_t)(X))
+#elif defined(__PTRDIFF_TYPE__) /* This case should work for GCC */
# define SQLITE_INT_TO_PTR(X) ((void*)(__PTRDIFF_TYPE__)(X))
# define SQLITE_PTR_TO_INT(X) ((int)(__PTRDIFF_TYPE__)(X))
#elif !defined(__GNUC__) /* Works for compilers other than LLVM */
# define SQLITE_INT_TO_PTR(X) ((void*)&((char*)0)[X])
# define SQLITE_PTR_TO_INT(X) ((int)(((char*)X)-(char*)0))
-#elif defined(HAVE_STDINT_H) /* Use this case if we have ANSI headers */
-# define SQLITE_INT_TO_PTR(X) ((void*)(intptr_t)(X))
-# define SQLITE_PTR_TO_INT(X) ((int)(intptr_t)(X))
#else /* Generates a warning - but it always works */
# define SQLITE_INT_TO_PTR(X) ((void*)(X))
# define SQLITE_PTR_TO_INT(X) ((int)(X))
I hoping to avoid maintaining a diff here, particularly since sqlite is
embedded so many places. I think this is the most portable and standard
compliant solution, but my view of the compiler and runtime space is far
from complete.
Thanks,
Brooks
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
