some users want to run tinyproxy on an as-needed basis in a terminal,
without setting it up permanently to run as a daemon/service.
in such use case, it is very annoying that tinyproxy didn't have
an option to log to stdout, so the user has to keep a second terminal
open to `tail -f` the log.
additionally, this precluded usage with runit service supervisor,
which runs all services in foreground and creates logfiles from the
service's stdout/stderr.
some people want to run tinyproxy with minimal configuration from
the command line (and as non-root), but tinyproxy insists on writing
a pid file, which only makes sense for usage as a service, hereby
forcing the user to either run it as root so it can write to the
default location, or start editing the default config file to work
around it.
and if no pidfile is specified in the config, it frankly doesn't
make sense to force creation of one anyway.
this causes a build failure on several platforms using older versions
of autotools or GNU make.
make[2]: Entering directory `src'
Makefile:670: *** missing separator (did you mean TAB instead of 8 spaces?). Stop.
make[2]: Leaving directory `src'
fixes#72
in the unlikely case that the user's C library has broken regex support,
she should probably update to a bugfree version.
in its full consequence, checking if individual functions works basically
require to test every single function in use, which is nonsensical.
since this check required to compile and run a code sample on the host,
it cannot be checked in cross-compile scenarios and as it defaulted to yes
(broken), causes build failure in any such scenario.
closes#1
Signed-off-by: John Spencer <maillist-tinyproxy@barfooze.de>
Reviewed-by: Michael Adam <obnox@samba.org>
This should make hash processing generally faster.
There is a treadeoff between memory footprint and
speed of processing. 10 KB instead of 1.2 KB of
hash table per process should not be a huge problem
even on very limited current systems.
Who really needs to stick to 32 buckets could
recompile. We could also think about making
this configurable at some point.
Signed-off-by: Michael Adam <obnox@samba.org>
This hash function distributes much better than the
original one. The effect is not as visible with
hashes taken modulo 32 than with a bigger modulus,
but it is there. And larger number of buckets migh
become possible in the future...
Reviewed-by: Michael Adam <obnox@samba.org>
