diff options
author | Nick Mathewson <nickm@torproject.org> | 2016-05-30 16:18:16 -0400 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2016-05-30 16:18:16 -0400 |
commit | 4f1a04ff9c74456c03ac67adb7ae780e4e77c71e (patch) | |
tree | a7dde276330e86e166945af726d1e4d325f18a67 /src/or/connection.c | |
parent | ce31db4326599c3f86307fca5286349150cb871e (diff) | |
download | tor-4f1a04ff9c74456c03ac67adb7ae780e4e77c71e.tar.gz tor-4f1a04ff9c74456c03ac67adb7ae780e4e77c71e.zip |
Replace nearly all XXX0vv comments with smarter ones
So, back long ago, XXX012 meant, "before Tor 0.1.2 is released, we
had better revisit this comment and fix it!"
But we have a huge pile of such comments accumulated for a large
number of released versions! Not cool.
So, here's what I tried to do:
* 0.2.9 and 0.2.8 are retained, since those are not yet released.
* XXX+ or XXX++ or XXX++++ or whatever means, "This one looks
quite important!"
* The others, after one-by-one examination, are downgraded to
plain old XXX. Which doesn't mean they aren't a problem -- just
that they cannot possibly be a release-blocking problem.
Diffstat (limited to 'src/or/connection.c')
-rw-r--r-- | src/or/connection.c | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/src/or/connection.c b/src/or/connection.c index e70b89767e..9362cf28fe 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -98,7 +98,7 @@ static int get_proxy_type(void); /** The last addresses that our network interface seemed to have been * binding to. We use this as one way to detect when our IP changes. * - * XXX024 We should really use the entire list of interfaces here. + * XXXX+ We should really use the entire list of interfaces here. **/ static tor_addr_t *last_interface_ipv4 = NULL; /* DOCDOC last_interface_ipv6 */ @@ -2932,7 +2932,7 @@ static void record_num_bytes_transferred(connection_t *conn, time_t now, size_t num_read, size_t num_written) { - /* XXX024 check if this is necessary */ + /* XXXX check if this is necessary */ if (num_written >= INT_MAX || num_read >= INT_MAX) { log_err(LD_BUG, "Value out of range. num_read=%lu, num_written=%lu, " "connection type=%s, state=%s", @@ -3759,7 +3759,7 @@ evbuffer_inbuf_callback(struct evbuffer *buf, connection_consider_empty_read_buckets(conn); if (conn->type == CONN_TYPE_AP) { edge_connection_t *edge_conn = TO_EDGE_CONN(conn); - /*XXXX024 check for overflow*/ + /*XXXX++ check for overflow*/ edge_conn->n_read += (int)info->n_added; } } @@ -3780,7 +3780,7 @@ evbuffer_outbuf_callback(struct evbuffer *buf, connection_consider_empty_write_buckets(conn); if (conn->type == CONN_TYPE_AP) { edge_connection_t *edge_conn = TO_EDGE_CONN(conn); - /*XXXX024 check for overflow*/ + /*XXXX++ check for overflow*/ edge_conn->n_written += (int)info->n_deleted; } } @@ -4139,7 +4139,7 @@ connection_handle_write_impl(connection_t *conn, int force) or_conn->bytes_xmitted += result; or_conn->bytes_xmitted_by_tls += n_written; /* So we notice bytes were written even on error */ - /* XXXX024 This cast is safe since we can never write INT_MAX bytes in a + /* XXXX This cast is safe since we can never write INT_MAX bytes in a * single set of TLS operations. But it looks kinda ugly. If we refactor * the *_buf_tls functions, we should make them return ssize_t or size_t * or something. */ |