[or-cvs] r17682: {tor} Remove fixed xxx020s; downgrade unfixed ones. (The unfixed o (tor/trunk/src/or)
nickm at seul.org
nickm at seul.org
Thu Dec 18 16:11:04 UTC 2008
Author: nickm
Date: 2008-12-18 11:11:03 -0500 (Thu, 18 Dec 2008)
New Revision: 17682
Modified:
tor/trunk/src/or/buffers.c
tor/trunk/src/or/circuituse.c
tor/trunk/src/or/connection.c
tor/trunk/src/or/dns.c
tor/trunk/src/or/geoip.c
tor/trunk/src/or/main.c
tor/trunk/src/or/networkstatus.c
Log:
Remove fixed xxx020s; downgrade unfixed ones.
(The unfixed ones are being downgraded to regular XXXs mainly on the rationale that they don't seem to be exploding Tor, and they were apparently not showstoppers for 0.2.0.x-final.)
Modified: tor/trunk/src/or/buffers.c
===================================================================
--- tor/trunk/src/or/buffers.c 2008-12-18 15:00:27 UTC (rev 17681)
+++ tor/trunk/src/or/buffers.c 2008-12-18 16:11:03 UTC (rev 17682)
@@ -1083,14 +1083,6 @@
tor_assert(out);
if (out->chunk) {
if (out->chunk->datalen) {
- /*XXXX020 remove this once the bug it detects is fixed. */
- if (!(out->pos < (off_t)out->chunk->datalen)) {
- log_warn(LD_BUG, "About to assert. %p, %d, %d, %p, %d.",
- out, (int)out->pos,
- (int)out->chunk_pos, out->chunk,
- out->chunk?(int)out->chunk->datalen : (int)-1
- );
- }
tor_assert(out->pos < (off_t)out->chunk->datalen);
} else {
tor_assert(out->pos == 0);
Modified: tor/trunk/src/or/circuituse.c
===================================================================
--- tor/trunk/src/or/circuituse.c 2008-12-18 15:00:27 UTC (rev 17681)
+++ tor/trunk/src/or/circuituse.c 2008-12-18 16:11:03 UTC (rev 17682)
@@ -234,7 +234,7 @@
/** Check whether, according to the policies in <b>options</b>, the
* circuit <b>circ makes sense. */
-/* XXXX021 currently only checks Exclude{Exit}Nodes. */
+/* XXXX currently only checks Exclude{Exit}Nodes. It should check more. */
int
circuit_conforms_to_options(const origin_circuit_t *circ,
const or_options_t *options)
@@ -933,7 +933,7 @@
if ((extend_info || purpose != CIRCUIT_PURPOSE_C_GENERAL) &&
purpose != CIRCUIT_PURPOSE_TESTING && !onehop_tunnel) {
/* see if there are appropriate circs available to cannibalize. */
- /* XXX020 if we're planning to add a hop, perhaps we want to look for
+ /* XXX if we're planning to add a hop, perhaps we want to look for
* internal circs rather than exit circs? -RD */
circ = circuit_find_to_cannibalize(purpose, extend_info, flags);
if (circ) {
Modified: tor/trunk/src/or/connection.c
===================================================================
--- tor/trunk/src/or/connection.c 2008-12-18 15:00:27 UTC (rev 17681)
+++ tor/trunk/src/or/connection.c 2008-12-18 16:11:03 UTC (rev 17682)
@@ -1990,16 +1990,6 @@
/* The other side's handle_write will never actually get called, so
* we need to invoke the appropriate callbacks ourself. */
connection_t *linked = conn->linked_conn;
- /* XXXX020 Do we need to ensure that this stuff is called even if
- * conn dies in a way that causes us to return -1 earlier? -NM
- * No idea. -RD */
- /* Actually, I'm pretty sure not. The big things here are to
- * tell the linked connection, "yes, you wrote some stuff!" so that
- * it can succeed as a appropriate. But if this side of the link
- * returned -1, then it couldn't process the data it got. That's
- * fairly rare, and doesn't really count as "success" for the other
- * side. -NM
- */
if (n_read) {
/* Probably a no-op, but hey. */
@@ -2043,7 +2033,7 @@
if (at_most == -1) { /* we need to initialize it */
/* how many bytes are we allowed to read? */
- /* XXXX020 too many calls to time(). Do they hurt? */
+ /* XXXX too many calls to time(). Do they hurt? */
at_most = connection_bucket_read_limit(conn, time(NULL));
}
Modified: tor/trunk/src/or/dns.c
===================================================================
--- tor/trunk/src/or/dns.c 2008-12-18 15:00:27 UTC (rev 17681)
+++ tor/trunk/src/or/dns.c 2008-12-18 16:11:03 UTC (rev 17682)
@@ -611,7 +611,7 @@
if (!exitconn->_base.marked_for_close) {
connection_free(TO_CONN(exitconn));
- //XXX020 ... and we just leak exitconn otherwise? -RD
+ // XXX ... and we just leak exitconn otherwise? -RD
// If it's marked for close, it's on closeable_connection_lst in
// main.c. If it's on the closeable list, it will get freed from
// main.c. -NM
@@ -1015,7 +1015,7 @@
assert_resolve_ok(resolve);
if (resolve->state != CACHE_STATE_PENDING) {
- /* XXXX020 Maybe update addr? or check addr for consistency? Or let
+ /* XXXX Maybe update addr? or check addr for consistency? Or let
* VALID replace FAILED? */
int is_test_addr = is_test_address(address);
if (!is_test_addr)
Modified: tor/trunk/src/or/geoip.c
===================================================================
--- tor/trunk/src/or/geoip.c 2008-12-18 15:00:27 UTC (rev 17681)
+++ tor/trunk/src/or/geoip.c 2008-12-18 16:11:03 UTC (rev 17682)
@@ -205,7 +205,7 @@
/* FFFF track full country name. */
geoip_parse_entry(buf);
}
- /*XXXX020 abort and return -1 if no entries/illformed?*/
+ /*XXXX abort and return -1 if no entries/illformed?*/
fclose(f);
smartlist_sort(geoip_entries, _geoip_compare_entries);
Modified: tor/trunk/src/or/main.c
===================================================================
--- tor/trunk/src/or/main.c 2008-12-18 15:00:27 UTC (rev 17681)
+++ tor/trunk/src/or/main.c 2008-12-18 16:11:03 UTC (rev 17682)
@@ -958,7 +958,7 @@
*/
if (time_to_check_for_expired_networkstatus < now) {
networkstatus_t *ns = networkstatus_get_latest_consensus();
- /*XXXX020 this value needs to be the same as REASONABLY_LIVE_TIME in
+ /*XXXX RD: This value needs to be the same as REASONABLY_LIVE_TIME in
* networkstatus_get_reasonably_live_consensus(), but that value is way
* way too high. Arma: is the bridge issue there resolved yet? -NM */
#define NS_EXPIRY_SLOP (24*60*60)
Modified: tor/trunk/src/or/networkstatus.c
===================================================================
--- tor/trunk/src/or/networkstatus.c 2008-12-18 15:00:27 UTC (rev 17681)
+++ tor/trunk/src/or/networkstatus.c 2008-12-18 16:11:03 UTC (rev 17682)
@@ -177,7 +177,7 @@
or_options_t *options = get_options();
const unsigned int flags = NSSET_FROM_CACHE | NSSET_DONT_DOWNLOAD_CERTS;
- /* XXXX020 Suppress warnings if cached consensus is bad. */
+ /* FFFF Suppress warnings if cached consensus is bad? */
filename = get_datadir_fname("cached-consensus");
s = read_file_to_str(filename, RFTS_IGNORE_MISSING, NULL);
@@ -1024,7 +1024,7 @@
if (connection_get_by_type_addr_port_purpose(
CONN_TYPE_DIR, &addr, ds->dir_port,
DIR_PURPOSE_FETCH_V2_NETWORKSTATUS)) {
- /* XXX020 the above dir_port won't be accurate if we're
+ /* XXX the above dir_port won't be accurate if we're
* doing a tunneled conn. In that case it should be or_port.
* How to guess from here? Maybe make the function less general
* and have it know that it's looking for dir conns. -RD */
@@ -1082,7 +1082,7 @@
return; /* There's an in-progress download.*/
if (consensus_waiting_for_certs) {
- /* XXXX020 make sure this doesn't delay sane downloads. */
+ /* XXXX make sure this doesn't delay sane downloads. */
if (consensus_waiting_for_certs_set_at + DELAY_WHILE_FETCHING_CERTS > now)
return; /* We're still getting certs for this one. */
else {
@@ -1252,7 +1252,7 @@
return NULL;
}
-/* XXXX020 remove this in favor of get_live_consensus. But actually,
+/* XXXX remove this in favor of get_live_consensus. But actually,
* leave something like it for bridge users, who need to not totally
* lose if they spend a while fetching a new consensus. */
/** As networkstatus_get_live_consensus(), but is way more tolerant of expired
More information about the tor-commits
mailing list