summaryrefslogtreecommitdiff
path: root/src/or/connection.c
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2016-05-30 16:18:16 -0400
committerNick Mathewson <nickm@torproject.org>2016-05-30 16:18:16 -0400
commit4f1a04ff9c74456c03ac67adb7ae780e4e77c71e (patch)
treea7dde276330e86e166945af726d1e4d325f18a67 /src/or/connection.c
parentce31db4326599c3f86307fca5286349150cb871e (diff)
downloadtor-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.c10
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. */