Principles
Cross-platform. The code can be compiled and run on multiple platforms: big-endian and little-endian, 32-bit and 64-bit. Database files also are fully portable between platforms - the file format is platform independent.
Backwards compatible. Future releases of ZIPVFS should be a drop-in replacement for the current release. The interface and file format are binary compatible between releases.
Principle of Least Surprise. The code does what programmers expect.
Self-contained. Minimal external dependences.
Timeless. The code is intended to have a useful lifespan of decades. The code is readable, understandable, and maintainable by people not yet born.
Constraints
No large stack frames. The system runs with 2K or less of stack space.
Bounded recursion.
No large memory allocations. The maximum memory allocation size is proportional to the size of the largest data row read or written, or the database page size, whichever is greater.
Minimal library support. Use SQLite-supplied utilities and services wherever possible. Acceptable routines from the standard library:
- memcpy()
- memset()
- memmove()
- strcmp()
Threadsafe but not threaded. ZIPVFS does not use threads itself but is safe to use within a multi-threaded application.
Robustness
I/O errors either self-correct or report back up to the application.
Corrupt database files are detected and reported back up to the application.
OOM errors are detected and handled either by making due without the requested memory or by reporting the error back up to the application.
No resource leaks. All resources are returned to the system when no longer required. This is true even following OOM errors, I/O errors, or other system problems.
Naming Conventions
All exported symbols begin with "zipvfs_". Any symbol that begins with "zipvfs_" is exported.
The only exported symbols are the defined and documented interfaces.
Exported symbols are lower-case with "_" seperating words.
Exported macros begin with "ZIPVFS_" or "SQLITE_".