Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

A Common Lisp library for accessing octet-addressed blocks of data

branch: master

Fetching latest commit…

Octocat-spinner-32-eaf2f5

Cannot retrieve the latest commit at this time

Octocat-spinner-32 doc
Octocat-spinner-32 sbcl-opt
Octocat-spinner-32 .gitignore
Octocat-spinner-32 LICENSE
Octocat-spinner-32 NEWS
Octocat-spinner-32 README
Octocat-spinner-32 macro-utils.lisp
Octocat-spinner-32 nibbles.asd
Octocat-spinner-32 package.lisp
Octocat-spinner-32 rt.lisp
Octocat-spinner-32 streams.lisp
Octocat-spinner-32 tests.lisp
Octocat-spinner-32 types.lisp
Octocat-spinner-32 vectors.lisp
README
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.