| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
|
|
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 (06e09cdd47eaa8f7e90ce2).
|
|
|
|
Conflicts:
src/or/circuitlist.c
|
|
Part of 11792.
(Uses the zlib-endorsed formula for memory needs for inflate/deflate
from "zconf.h".)
|
|
This may improve our compression ratios.
fix for 11787
|
|
of libevent, openssl and zlib. Partially implements #6384.
|
|
|
|
|
|
Conflicts:
configure.in
src/or/circuitbuild.c
|
|
|
|
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.
|
|
bug3122_memcmp_022
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 commit is _exactly_ the result of
perl -i -pe 's/\bmemcmp\(/tor_memcmp\(/g' src/*/*.[ch]
perl -i -pe 's/\!\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*==\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*!=\s*tor_memcmp\(/tor_memneq\(/g' src/*/*.[ch]
git checkout src/common/di_ops.[ch]
git checkout src/or/test.c
git checkout src/common/test.h
|
|
About 860 doxygen-less things remain in 0.2.2
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/common/test.h
src/or/test.c
|
|
|
|
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.
|
|
Conflicts:
src/common/test.h
src/or/test.c
|
|
|
|
|
|
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.
|
|
|
|
|
|
REVERSE_INULL. This is what we get for bragging about being down to 0 issues.
svn:r18096
|
|
redefined an unsigned field in zlib.h to be signed. I am quite sure this makes me more secure somehow.
svn:r17892
|
|
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
|
|
svn:r13412
|
|
Fix some hard to trigger but nonetheless real memory leaks spotted by an anonymous contributor. Needs review. Partial backport candidate.
svn:r13147
|
|
svn:r12786
|
|
Fix/note some relatively trivial mem usage issues
svn:r10905
|
|
svn:r9634
|
|
Resolve 56 DOCDOC comments.
svn:r9594
|
|
Update copyright dates.
svn:r9570
|
|
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
|
