SHGetSpecialFolderPath is in Shell32.dll and the RegOpenKey (et al) and
CryptGenRandom (et al) functions are in -ladvapi32.dll. MinGW is "nice"
and brings those in automatically, but specify them explicitly for
other tool chains.
Modified the `html_replace' function so that it returns the length of
the replacement string instead of the string itself. This is used to
easily check for overflows of the `new_size' variable in the first for
loop of the `evhttp_htmlescape' function, and thus potential out of
bounds writes in the second for loop (if an overflow occurs in
new_size, then new_size < old_size). Also check that new_size + 1
doesn't overflow in mm_malloc(new_size + 1).
Removed the `scratch_space' variable from the `evhttp_htmlescape'
function since it wasn't actually used; also removed the `buf'
variable from the `evhttp_htmlescape' function since it was only used
by `scratch_space'.
"I'm not sure if you'll like my use of the limited broadcast address
for simulating an ENETUNREACH error with a TCP connection, but it's
the best that I could think of. Basically, we want to trigger a
non-EINPROGRESS error in evutil_socket_connect() immediately at the
connect() in order to bring about the assertion in the
evhttp_connection_fail() error handling code."
Patch in question:
- Fix the case when failed evhttp_make_request() leaved request in the queue.
- http://levent.git.sourceforge.net/git/gitweb.cgi?p=levent/libevent;a=commit;h=0d6622e
The above patch introduces a failing assertion in
evhttp_connection_fail(). This happens because the patch defers the
assignment of the outstanding request to the evcon->requests list,
while evhttp_connection_fail() assumes that the request lies in the
list.
One scenario in which this can happen is when the request list is
empty and a connection is made to an unreachable host. The assertion
will then fail after bufferevent_socket_connect() errors out (with
ENETUNREACH in my case).
I took this fix from Tor (commit 1a52e39c22d5, author Nick Mathewson,
Copyright (c) 2007-2011, The Tor Project, Inc.) and adapted it slightly
for libevent.
Apparently, kevent fails gracefully if there is not enough space in its
output events array to report every _event_... but it just dies and returns
-1 if there is not enough space to report every _error_.
There are a couple of possible fixes here. One would to handle -1
returns from kevent better by re-growing the array and retrying... but
that seems a little error prone. Instead, I'm just going to say that
the events array must be large enough to handle all the errors.
This patch also adds a unit test designed to make sure that our
many-events-out code works even if not all the events are added at
once.
This was a regression on 2.0.10-stable: clang was warning about
values that were unused (because event_debug wasn't using them unless
USE_DEBUG was defined). Found by Sebastian Hahn.
When compiling using clang (2.9 or lower) do not enable
-Wnormalized=id or -Woverride-init when --enable-gcc-warnings
or --enable-gcc-warnings-advisory is set as these options
are unsupported.
This commit is based on a patch for Tor
(git commit 56bdc844ba68ac0911efc7ad3398f1eafeaaac76 by Steven
Murdoch), Copyright (c) 2007-2011, The Tor Project, Inc.
Previously, we did stuff like
if (!lock)
EVTHREAD_ALLOC_LOCK(lock,0);
for the evsig base global lock, the arc4random lock, and the debug_map
lock. But that's potentially racy! Instead, we move the
responisiblity for global lock initialization to the functions where
we set up the lock callbacks.
(Rationale: We already require that you set up the locking callbacks
before you create any event_base, and that you do so exatly once.)
First of all, it is totally okay to have an address end with .255,
depending on what your netmask is, so we shouldn't reject a local
address if it ends with .255.
Second, our check for ending with .255 was broken. So was our check
for class-d addresses.
Found by Dave Hart.
