o rse: memory chunk maintainance
  A piece of memory usually has the following 4 attributes which fully
  describe it:

  memory location: <pointer,length,size,refcount>
  memory type:     STACK|HEAP|SHMEM|CUSTOM
  memory scope:    LOAN|GIFT|[COPY]
  memory access:   READ_ONLY|READ_WRITE

  With the current al_chunk_t/al_buffer_t such a description is only
  partly possible, although IMHO (after efficiency) this flexibility in
  describing arbitrary memory chunks has to be #1 priority.

  Currently only al_attach_buffer() allows insertion of externally
  provided memory chunks. But these then have to be malloc(3)'ed and
  are not allowed to be allocated differently. For this the CUSTOM type
  would allow arbitrary memory chunks to be specified for an application
  provided destruction callback exists.

o rse: al.pod, DESCRIPTION:
  perhaps add the buzzwords "zero-copy" and "efficient" somewhere just
  to make sure people recognize that OSSP al is not "just another
  trivial buffer library" ;)
  
o rse: al.pod, al_attach_buffer:
  scope still does not say anything about the content, i.e., is it
  allowed that the application still changes the content (as long as the
  size does not change)?

o rse: recommended renamings: 
  public:
    al_txalloc     -> al_tx_create
    al_txfree      -> al_tx_destroy
    al_traverse    -> al_traverse_start
    al_traverse_cb -> al_apply
  private:
    new_buffer     -> buffer_new
    dispose_buffer -> buffer_dispose
    make_buffer    -> buffer_make
    new_chunk      -> chunk_new
    split_chunk    -> chunk_split
    dispose_chunk  -> chunk_dispose

o thl: sanity checks and return of AL_ERR_ARG

o thl: Es fehlt eine al_configure() call mit dem man die al_memops_t
  beeinflussen kann.

o thl: Beim splicen entstehen shared buffers und deren bisherige Behandlung
  ist rudimentaer, sorgt aber bereits fuer merklich Overhead usecount
  in al_buffer_t). Das transferieren von Teilen solcher shared buffer
  von einer al in eine andere ist derzeit ein Limit der Library.
  Ein versehentliches anhaengen von Daten in anscheinend freie
  Bufferbereiche, die aber doch von anderen Chunks genutzt werden,
  wird derzeit schlicht durch Totalverweigerung der Nutzung von
  evtl. freien Bufferbereichen bei shared buffers verhindert, indem
  AL_CHUNK_RESERVE() einfach immer "null Platz" fuer shared buffer
  (usecount > 1) zurueckgibt. Aehnliches gilt fuer das gift/loan
  Verhalten, wegen al_attach_buffer() muss extra ein freemem flag
  mitgescheift werden. Aber es wird gemacht und
  funktioniert und ich wuesste auch keinen besseren Weg.
 
o thl: Es ist weder in der Doku noch im Code beruecksichtigt, dass
  die Assembly List zwischen al_traverse() und al_txfree() nicht
  veraendert werden darf. Ist auch nicht ganz so einfach zu erklaeren,
  denn veraendern heisst z.B. splicen. Appenden und prependen stoert
  wohl nicht. Es gehen aber die waehrend des traversals dazugekommenen
  Daten dem al_traverse_next() durch die Lappen, da die Datenmenge beim
  al_traverse() berechnet wird.
 
o rse: the library is not threadsafe nor even reentrant because there
  are two static variables: alc_freelist, alc_freecount.

o rse: the list.h macros lack a common prefix.