Skip to content


Subversion checkout URL

You can clone with
Download ZIP
A Common Lisp library for accessing octet-addressed blocks of data
Common Lisp
Branch: master
Failed to load latest commit information.
doc release v0.11
sbcl-opt add support for inlining 16-bit operations on x86-64
.gitignore add .gitignore
.travis.yml use only CL-interned symbols in .travis.yml
LICENSE add LICENSE file; better late than never
macro-utils.lisp Changed symbol creation functions so that they also work in Allegro C…
package.lisp add stream functions for floats
rt.lisp update rt.lisp
streams.lisp fix mis-parenthesization of END in READ-INTO-LIST*
tests.lisp Fix type declaration.
types.lisp Exposed octet-vector types; added constructors


When dealing with network protocols and file formats, it's common to
have to read or write 16-, 32-, or 64-bit datatypes in signed or
unsigned flavors.  Common Lisp sort of supports this by specifying
:ELEMENT-TYPE for streams, but that facility is underspecified and
there's nothing similar for read/write from octet vectors.  What most
people wind up doing is rolling their own small facility for their
particular needs and calling it a day.

This library attempts to be comprehensive and centralize such
facilities.  Functions to read 16-, 32-, and 64-bit quantities from
octet vectors in signed or unsigned flavors are provided; these
functions are also SETFable.  Since it's sometimes desirable to
read/write directly from streams, functions for doing so are also
provided.  On some implementations, reading/writing IEEE singles/doubles
(i.e. SINGLE-FLOAT and DOUBLE-FLOAT) will also be supported.

In addition to centralizing such facilities, NIBBLES also aspires to
become a place where compiler optimizations can be written once and used
everywhere.  The intention is that (eventually):

  (nibbles:sb32ref/le vector index)

will compile (with any necessary safety checks) to a MOVSX instruction
on an x86oid processor in SBCL (or other implementations) if VECTOR and
INDEX are of appropriate types.

I remember reading a post on comp.lang.lisp that suggested the designers
of Common Lisp ignored the realities of octets and endianness and so
forth.  This library is a small step towards remedying that deficiency.
Something went wrong with that request. Please try again.