We add a compression level argument to tor_zlib_new, and use it to
determine how much memory to allocate for the zlib object. We use the
existing level by default, but shift to smaller levels for small
requests when we have been over 3/4 of our memory usage in the past
half-hour.
Closes ticket 11791.
Otherwise, when we're out of input *and* finalizing, we might report
TOR_ZLIB_OK erroneously and not finalize the buffer.
(I don't believe this can happen in practice, with our code today:
write_to_buf_zlib ensures that we are never trying to write into a
completely empty buffer, and zlib says "Z_OK" if you give it even
one byte to write into.)
Fixes bug 11824; bugfix on 0.1.1.23 (06e09cdd47).
We'll still need to tweak it so that it looks for includes and
libraries somewhere more sensible than "where we happened to find
them on Erinn's system"; so that tests and tools get built too;
so that it's a bit documented; and so that we actually try running
the output.
Work done with Erinn Clark.
Conflicts throughout. All resolved in favor of taking HEAD and
adding tor_mem* or fast_mem* ops as appropriate.
src/common/Makefile.am
src/or/circuitbuild.c
src/or/directory.c
src/or/dirserv.c
src/or/dirvote.c
src/or/networkstatus.c
src/or/rendclient.c
src/or/rendservice.c
src/or/router.c
src/or/routerlist.c
src/or/routerparse.c
src/or/test.c
Here I looked at the results of the automated conversion and cleaned
them up as follows:
If there was a tor_memcmp or tor_memeq that was in fact "safe"[*] I
changed it to a fast_memcmp or fast_memeq.
Otherwise if there was a tor_memcmp that could turn into a
tor_memneq or tor_memeq, I converted it.
This wants close attention.
[*] I'm erring on the side of caution here, and leaving some things
as tor_memcmp that could in my opinion use the data-dependent
fast_memcmp variant.
This should make us conflict less with system files named "log.h".
Yes, we shouldn't have been conflicting with those anyway, but some
people's compilers act very oddly.
The actual change was done with one "git mv", by editing
Makefile.am, and running
find . -name '*.[ch]' | xargs perl -i -pe 'if (/^#include.*\Wlog.h/) {s/log.h/torlog.h/; }'
From the code:
zlib 1.2.4 and 1.2.5 do some "clever" things with macros. Instead of
saying "(defined(FOO) ? FOO : 0)" they like to say "FOO-0", on the theory
that nobody will care if the compile outputs a no-such-identifier warning.
Sorry, but we like -Werror over here, so I guess we need to define these.
I hope that zlib 1.2.6 doesn't break these too.
Possible fix for bug 1526.
Some *_free functions threw asserts when passed NULL. Now all of them
accept NULL as input and perform no action when called that way.
This gains us consistence for our free functions, and allows some
code simplifications where an explicit null check is no longer necessary.
The subversion $Id$ fields made every commit force a rebuild of
whatever file got committed. They were not actually useful for
telling the version of Tor files in the wild.
svn:r17867
Fix all remaining shorten-64-to-32 errors in src/common. Some were genuine problems. Many were compatibility errors with libraries (openssl, zlib) that like predate size_t. Partial backport candidate.
svn:r13665
Add some checks in torgzip.c to make sure we never overflow size_t there. Also make sure we do not realloc(list,0) in container.c. Backport candidate.
svn:r13587
Removing the last DOCDOC comment hurt so much that I had to use Doxygen to identify undocumented macros and comments, and add 150 more DOCDOCs to point out where they were. Oops. Hey, kids! Fixing some of these could be your first Tor patch!
svn:r9477
Try to compile with fewer warnings on irix64's MIPSpro compiler /
environment, which apparently believes that:
- off_t can be bigger than size_t.
- only mean kids assign things they do not subsequently inspect.
I don't try to fix the "error" that makes it say:
cc-3970 cc: WARNING File = main.c, Line = 1277
conversion from pointer to same-sized integral type (potential portability
problem)
uintptr_t sig = (uintptr_t)arg;
Because really, what can you do about a compiler that claims to be c99
but doesn't understand that void* x = NULL; uintptr_t y = (uintptr_t) x;
is safe?
svn:r8948
The otherwise regrettable MIPSpro C compiler warns about values set but never used, and about mixing enums and ints; these are good warnings, and so should be fixed. This removes some dead code and some potential bugs. Thanks to pnx.
svn:r8664
