[tor-bugs] #6465 [Tor Relay]: Build abstraction layer around TLS
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Wed Sep 19 13:39:22 UTC 2012
#6465: Build abstraction layer around TLS
-----------------------+----------------------------------------------------
Reporter: andrea | Owner: andrea
Type: project | Status: needs_review
Priority: major | Milestone: Tor: 0.2.4.x-final
Component: Tor Relay | Version: Tor: unspecified
Keywords: | Parent:
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by andrea):
Responses to part 2 (points I generally agree with/am fine with going
ahead and adjusting without debate):
> Last general thing: Some of these functions should probably take const
> channel_t*, not channel_t*.
Okay.
> A general thing: this branch doesn't actually compile for me. I get lots
> of warnings like this:
>
> src/or/channel.c:1595: warning: format %lu expects type long unsigned
int,
> but argument 7 has type uint64_t
>
> Please try building on a more recent GCC and/or a 64-bit platform and/or
a
> 32-bit platform and/or with a recent clang -- whatever you haven't tried
yet.
Yeah, that should change.
> Typo in comment in channel.h : "see thw channel_t"
Yeah, I obviously meant 'thaw channel_t' :)
> Should channel_more_to_flush() check outgoing_queue rather than
cell_queue?
> Should cell_queue be renamed incoming_queue for consistency? I think it
> should.
Yeah, yes to both I think. Good catch with channel_more_to_flush().
> In channel_process_incoming, do we want to process that queue in-order?
It
> seems that doing the DEL_CURRENT approach is likely to have weird
> consequences. Perhaps it would be better to extract all the members into
a
> separate list (smartlist_add_all(), smartlist_clear()), then process the
> separate list, then free it.
Yeah, I think that's probably better.
> It seems like channel_process_cells, channel_queue_cell, and
> channel_queue_var_cell have some common code that should be extracted.
Yeah, probably.
> The first part of channel_free_all() seems redundant with
> channel_run_cleanup()
Yeah, that can change.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6465#comment:27>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list