| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
timer with an unspecified update rate and epoch. It is only used
inside the entropy sources to provide some timing-dependent
randomness. However, it is easier and basically 'as good' to treat the
timers as entropy sources in their own right and feed their output
directly into an entropy pool.
This commit removes Library_State::system_clock and all calls to that
function.
|
|
|
|
| |
fruit for removal.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Library_State, in libstate.{h,cpp}). It causes numerous 'interesting'
problems with threads, etc, and the best solution here is to move to
more or less an object-capability model, where the only objects that
a piece of code can access are those which can be referenced through
its arguments.
First things first, remove the UI 'pulse' code. It is neither necessary
nor sufficient for writing proper GUI/event driven code using Botan, has
likely never been used in real code, and, given that, causes a distressing
amount of overhead in terms of function calls made.
|
|
|
|
| |
to access it.
|
|
|
|
|
| |
static function of the Timer base class - since that is the only code which
actually needs to access it.
|
|
|
|
|
| |
whatever the current user/group is. If you wish to override, edit the
makefile or override the INSTALL_CMD_* variables on the command line.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead allocate a reference to a mutex locally and use the more typical
Mutex_Holder RAII object.
Named_Mutex_Holder (and in particular the string->mutex mappings contained
in the global state) have been found to be pretty expensive in at least
some situations (see post by Jack Cummings to monotone-devel 2008-03-12),
and doesn't really buy us that much in terms of ease of use. Also, it
relies on the global state object, which has shown itself to be a rich
source of race conditions and locking bugs. The intent is to incrementally
remove all of the shared / global state and require applications to maintain
that state where necessary.
|
| |
|
| |
|
| |
|
|
|
|
| |
to represent the message number in a Pipe
|
|
|
|
|
| |
Previously the only method allowed was with a pathname, which is pretty
inflexible since it prevents you from using devices like std::cin, etc
|
|
|
|
|
|
| |
identification purposes) when passing in a std::ostream, since there
is no portable way to go from a std::ostream to the file or other device
that it names
|
| |
|
| |
|
|
|
|
|
| |
updated dates on files that have actually changed this year. This makes
the diff across versions readable again.
|
| |
|
|
|
|
| |
Monotone mailing list, it was needed for a build.
|
|
|
|
|
| |
expansion. While I would prefer to have the compiler to this, using GCC 4.1.2
it is 4% faster on a Core2 Q6600 with the loops partially unrolled.
|
|
|
|
|
|
|
|
| |
takes advantage of unaligned reads/writes being legal for some extra performance,
but should be rewritten to use SSE2 and non-termporal writes.
Most of the functions in bit_ops.cpp are implemented by x86-64, just not
easily accessible from C++
|
|
|
|
| |
DEFAULT_BUFFERSIZE (normally 4K); measurably faster on a Core2
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the word read/write functions will be faster through the use of
(slightly unsafe) pointer manipulations. On some CPUs (like SPARC),
these antics can cause crashes (usually visible by SIGBUS) if what you
are attempting to read or write as an integer is not aligned on a word
boundary. However they are safe on x86 and x86-64.
Performance increases across the board on a Core2. In most algorithms
the improvement seems to be about 3%, except a few standouts like RC6
(15%), MD4 (20%), RIPEMD-128 (8%). Will be better with faster xor_buf
and byte swapping.
|
| |
|
|
|
|
| |
harmless, to avoid a valgrind warning
|
|
|
|
| |
wrong, and didn't work at all. New corrected (and tested) version.
|
|
|
|
|
|
|
| |
with the last one being both one of the input values and the output carry
register, since almost always they were in fact the same variable.
Also update the x86 and x86-64 modules.
|
|
|
|
| |
writing of it in assembly.
|
|
|
|
|
|
|
| |
for 64-bit to not use 64-bit constants - that way GCC won't complain everwhere.
Plan is for a module to replace all of these with asm (bswap, xchg on x86),
at least for x86-64
|
|
|
|
|
|
|
| |
but might as well keep it up to date. And it's easier to do it once with
a 'perl -pi' command than to update each file over time.
Apologies to anyone looking at diffs.
|
|
|
|
| |
fewer explicit coercions.
|
|
|
|
| |
for struct stat
|
|
|
|
|
|
|
| |
Has not been tested on all of the systems listed, and on many of them it
won't be relevant anyway since /dev/random and company only exist on some
of them (Linux, BSDs, recent Solaris, and it looks like recent AIX and
HP-UX as well).
|
| |
|
| |
|
|
|
|
| |
commonly used options are near the top.
|
| |
|
|\
| |
| |
| | |
and '9fe0310805932b889bdfa17c9213f2b97d47ab6a'
|
| |
| |
| |
| |
| |
| | |
explicit :: (it is unfortunate that there is no good way to detect all
of such calls in an automated manner). Also use new-style casts in parts
of the zlib code.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
/dev/urandom /dev/random
to
/dev/random /dev/srandom /dev/urandom
because the es_dev module can handle reads from devices that may block
without ever blocking for an unbounded amount of time.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
iostreams, it uses unbuffered Unix I/O syscalls and is careful to avoid
blocking for more than short amounts of time.
|
| | |
|
| | |
|
| |
| |
| |
| | |
after assignment.
|
| |
| |
| |
| |
| |
| | |
by Joel Low on the mailing list, the STL container types have only a
single version of push_back(), along with variations of insert() for
handling range-based appending.
|
| |
| |
| |
| |
| | |
doesn't go beyond that. Since 1.4 itself is pretty obsolete, and 1.6
is now in wide use, just drop the doc in mainline
|
| | |
|
| |
| |
| |
| | |
Change all callers in the library and self-test code.
|