Changes in version 0.1.1.9000                      

                 Changes in version 0.1.1 (2026-09-28)                  

CRAN release: 2026-09-28.

  - Fixes the undefined behaviour CRAN's clang-UBSAN and gcc-UBSAN
    checks reported in the bundled 'libmdbx' sources. 'libmdbx' read and
    wrote 16-, 32- and 64-bit values through misaligned pointers on
    x86-64 and arm64; it is now built with MDBX_UNALIGNED_OK=0, which
    routes those accesses through byte copies. Three internal structures
    that 'libmdbx' deliberately indexes past their declared length are
    now C99 flexible array members, or are indexed through a pointer, so
    gcc's -fsanitize=bounds-strict no longer reports them. Nothing
    observable changes: on-disk format, allocation sizes and results are
    identical.

                 Changes in version 0.1.0 (2026-09-27)                  

CRAN release: 2026-09-27.

  - Initial version.

  - mdbx_env_open() refuses a path this process already has open, naming
    the conflict, rather than passing on the lock file's own failure
    (EAGAIN on macOS). Different spellings of one environment -- a
    relative path against an absolute one, a symlinked directory, the
    data file of a subdir = TRUE layout -- are recognised as the same
    path (#2).

  - mdbx_dbi_open() names the database it could not open, and says why
    create = TRUE needs a write transaction, instead of reporting
    libmdbx's MDBX_NOTFOUND and EACCES (#3).

  - ?mdbx-concurrency no longer claims that two environments opened on
    the same file in one session are independent; they never were.

  - mdbx_dbi_drop() refuses to empty the main database while the
    environment holds any named database. A named database is a record
    in the main database, so 'libmdbx' purges every one of them along
    with it -- silent, irreversible, and the opposite of what "removes
    every record but keeps the database" leads a caller to expect. Drop
    them by name first, or delete the main database's keys individually.

  - mdbx_dbi_drop(db = NULL, delete = TRUE) is now an error. The main
    database records the named ones and cannot be deleted; 'libmdbx'
    silently ignores the request and reports success, so the caller was
    told a deletion had happened when it had not.