This document lists some of the known bugs:

* Due to compatibility issues with RedHat's gcc 2.96 compiler, std::vector
  accesses are done using [] instead of at(). This is generally OK (we are only
  *supposed* to read valid indexes), but at times bugs have caused it so that
  an invalid index is accessed, which is either not noticed until later, or
  causes a SIGSEGV on the spot.

  Other GCC related problems: we can't use std::is* or std::to* because GCC pre
  3.0 (including RedHat's 2.96) barfs on it. And std::string is missing the
  clear() function (this is not a real problem, just an annoyance).

  There are various other problems related to linkage, std::multimap handling,
  and so forth that I won't bother getting into here.

  Currently there are a fairly large number of workarounds for GCC 2.x. Botan
  1.4.x will be the last stable series that supports this compiler; all said
  workarounds will be removed in 1.5.0 (and stable trees past 1.4.x). As of now
  (June 2004) almost all operating systems that have used 2.95.x or 2.96 in the
  past (most Linux distros, MacOS X 10.1, NetBSD 1.6, FreeBSD 4, QNX 6.2) have
  been replaced by newer versions that use a more modern GCC.

* In some of the nastier cases (like indefinite length constructions), the BER
  decoder will use small integer multiples the total size of the object. In the
  usual case of something being a few tens/100s of kilobytes at most, this is
  not a big deal, but reading in a 50 meg BER file could be very costly in some
  cases.

* Several places assume ASCII characters. However as of 1.3.5 this is (or
  should be) contained to charset.cpp; everything else should be character set
  independent. The version as shipped assumes ASCII/Latin-1, and modifications
  would be needed to use it on EBCDIC systems.

  I suspect there are other cases I'm not thinking of, and it's likely that
  EBCDIC will need a significant amount of debugging (and thought) to work
  correctly.

* T61 strings are treated like ISO 8859-1 strings, even though this is
  technically incorrect. Since everyone else does this too, it shouldn't be a
  problem.

* X509_Time::X509_Time(u64bit) is not thread safe (it uses gmtime).
  Unfortunately we can't really rely on gmtime_r being available. The window
  of contention is minimal (we copy the return value into a buffer allocated on
  the stack) but it is there. If you're very paranoid about this, edit the
  get_tm function in asn1_tm.cpp to use gmtime_r

* There are various low-level threading issues, but mostly in places where a
  threaded program should not be touching things (set_mutex_type, for example).
  The list of such unsafe functions should be documented.

* There is a nasty little problem with the build system. Namely, because we
  pass -Iinclude, some (most? all?) compilers will look in the include/
  directory before looking in /usr/include, etc. This can cause conflicts, when
  a header in /usr/include #include's something like 'mutex.h', expecting to
  get /usr/include/mutex.h, but instead gets the library's mutex.h.

  Thankfully this only affects building, applications aren't bothered by this
  (since they use the standard include paths). It should be fixed, but I'm not
  a sufficient make wizard to figure out how to do so. It's a really stupid
  problem, considering that our code doesn't even want to see the headers as
  <header.h>; all it wants is <botan/header.h>

  The reason it exists is because many modules want to add/replace/ignore
  various headers in the 'stock' include/; there is no way to do this
  easily without doing what we're doing now (that I can see, anyway).
