• Top
    • Documentation
    • Books
      • Cert.pl
      • Community-books
      • Project-dir-alist
      • Bookdata
      • Book-hash
        • Book-hash-mismatch
        • Uncertified-books
        • Sysfile
        • Show-books
        • Best-practices
        • Books-reference
        • Where-do-i-place-my-book
        • Books-tour
      • Recursion-and-induction
      • Boolean-reasoning
      • Debugging
      • Projects
      • Std
      • Proof-automation
      • Macro-libraries
      • ACL2
      • Interfacing-tools
      • Hardware-verification
      • Software-verification
      • Testing-utilities
      • Math
    • Book-hash

    Book-hash-mismatch

    Deeming a book uncertified because of a book-hash mismatch

    When include-book is invoked, the specified book may be considered uncertified by ACL2 because its book-hash — which by default is an alist specifying the book's size and write-date, but could be a checksum — does not match what was expected. In that case you will typically see a warning such as the following, which instead will be an error if this occurs during certification. In this topic, we explain how this warning can occur.

    ACL2 Warning [Uncertified] in ( INCLUDE-BOOK "foo" ...):
    The certificate for "/Users/kaufmann/temp/foo.lisp" lists the book-
    hash of that book as ((:BOOK-LENGTH . 38) (:BOOK-WRITE-DATE . 3674050905)).
    But its book-hash is now computed to be
    ((:BOOK-LENGTH . 39) (:BOOK-WRITE-DATE . 3674050914)).
    See :DOC book-hash-mismatch.

    Probably the simplest way for such a mismatch to occur is if you change the book after certifying it, and then try to include the book. In the example message displayed above, the book-hash for foo.lisp stored into foo.cert was 516310554. But then foo.lisp was edited (in this case, by adding a single newline character), and ACL2 complained because at include-book time it computed a different book-hash for that book.

    The mismatch might occur on a book that is being included while including a superior book. For example, suppose that the act of evaluating (include-book "bk1") triggers evaluation of the event (include-book "bk2") from bk1.lisp, which similarly in turn causes evaluation of the event (include-book "bk3") from bk2.lisp. Now certify bk3.lisp, then bk2.lisp, and finally bk1.lisp. So far, so good. But now suppose we edit the lowest-level book, bk3.lisp. We will likely get a warning (or error, if during book certification) such as the one displayed above when evaluating (include-book "bk1"), complaining that the book-hash for bk3.lisp has changed — followed by warnings complaining about inclusions of uncertified books by superior books.

    There are several ways for a book-hash in a .cert file to become invalid, that is, to fail to match a recomputation of the book-hash when later including the book. All such mismatches are due to a difference between the value of a book-hash at certification time and at later include-book time; see book-hash.

    Note that it is possible to mix alist and checksum book-hash values. The key is to avoid conflicts between book-hash values stored for the same book in different .cert files. The following example works fine, because there is no such conflict: the book "sub" is associated with a book-hash checksum in sub.cert, which provides that same checksum as the book-hash value for "sub" in top.cert; and the book "top" is associated with a book-hash alist in top.cert.

    (certify-book "sub")
    (u)
    (assign book-hash-alistp t)
    (certify-book "top") ; contains the event (include-book "sub")
    (u)
    (include-book "top") ; no problem!

    However, if we instead evaluate the following forms in a fresh ACL2 session, the last one causes an error, because a checksum serves as the book-hash for "sub" in top.cert, but at include-book time the book-hash for "sub" in sub.cert is an alist, not a checksum.

    (certify-book "sub")
    :u
    (certify-book "top") ; contains the event (include-book "sub")
    :u
    (assign book-hash-alistp t)
    (certify-book "sub") ; now the book-hash for sub is an alist
    :u
    ; Error: mismatch for book-hash values for "sub" in
    ;        new sub.cert and earlier top.cert.
    (include-book "top")

    That said, ACL2 does not care about the current value of state global book-hash-alistp at include-book time. For example, the following works without error: ACL2 sees the checksum stored in sub.cert, so at include-book time it computes a checksum for the book "sub", not an alist, even though 'book-hash-alistp has value t.

    (assign book-hash-alistp nil)
    (certify-book "foo")
    (assign book-hash-alistp t)
    (include-book "foo")

    We conclude by discussing a rather insidious book-hash mismatch that can occur when including a book using an ACL2 executable that differs from the executable that was used when certified the book. Here is an example. Consider a book, "foo.lisp", containing the event (include-book "tools/remove-hyps" :dir :system). Suppose we have ACL2 executables acl2-cksum and acl2-alist, in different ACL2 directories. Also suppose that we have certified (disjoint copies of) the community-books with each of these ACL2 executables, where we used ACL2_BOOK_HASH_ALISTP=NIL in our "make" command with acl2-cksum but not with acl2-alist. Now suppose we certify "foo.lisp" using acl2-cksum but then, in a session with acl2-alist, we include that same book. Then we will see a warning beginning as displayed below. It complains that the book-hash required of books/tools/remove-hyps.cert according to foo.cert — which was created using acl2-cksum — differs from the book-hash in the .cert file of the copy of that book that is under the directory of the currently running ACL2, acl2-alist.

    ACL2 Warning [Uncertified] in ( INCLUDE-BOOK "foo" ...):  After including
    the book "/Users/smith/temp/foo.lisp":
    
    -- its certificate requires the book "/Users/smith/acl2/books/tools/remove-
    hyps.lisp" with certificate annotations
      ((:SKIPPED-PROOFSP) (:AXIOMSP) (:TTAGS))
    and book hash 1958615726, but we have included a version of "remove-hyps"
    with certificate annotations
      ((:SKIPPED-PROOFSP) (:AXIOMSP) (:TTAGS))
    and book-hash ((:BOOK-LENGTH . 14650) (:BOOK-WRITE-DATE . 3656629263)),
    so book recertification is probably required;