[or-cvs] r12608: easy tweaks on r12607 (tor/trunk/src/or)
arma at seul.org
arma at seul.org
Thu Nov 29 15:30:33 UTC 2007
Author: arma
Date: 2007-11-29 10:30:32 -0500 (Thu, 29 Nov 2007)
New Revision: 12608
Modified:
tor/trunk/src/or/buffers.c
tor/trunk/src/or/or.h
tor/trunk/src/or/rendservice.c
tor/trunk/src/or/routerparse.c
Log:
easy tweaks on r12607
Modified: tor/trunk/src/or/buffers.c
===================================================================
--- tor/trunk/src/or/buffers.c 2007-11-29 15:25:04 UTC (rev 12607)
+++ tor/trunk/src/or/buffers.c 2007-11-29 15:30:32 UTC (rev 12608)
@@ -288,14 +288,10 @@
int i, n_to_skip, n_to_free;
char **ptr;
if (free_all) { /* Free every one of them */
- /* Just a consideration: Is this log statement really useful on
- * info level? -KL */
log_debug(LD_GENERAL, "Freeing all %d elements from %d-byte freelist.",
list->len, (int)list->chunksize);
n_to_free = list->len;
} else { /* Skip over the slack and non-lowwater entries */
- /* Just a consideration: Is this log statement really useful on
- * info level? -KL */
log_debug(LD_GENERAL, "We haven't used %d/%d allocated %d-byte buffer "
"memory chunks since the last call; freeing all but %d of "
"them",
@@ -379,8 +375,6 @@
if (buf->mem)
raw = tor_realloc(RAW_MEM(buf->mem), ALLOC_LEN(new_capacity));
else {
- /* Just a consideration: Is this log statement really useful on
- * info level? -KL */
log_debug(LD_GENERAL, "Jumping straight from 0 bytes to %d",
(int)new_capacity);
raw = tor_malloc(ALLOC_LEN(new_capacity));
Modified: tor/trunk/src/or/or.h
===================================================================
--- tor/trunk/src/or/or.h 2007-11-29 15:25:04 UTC (rev 12607)
+++ tor/trunk/src/or/or.h 2007-11-29 15:30:32 UTC (rev 12608)
@@ -1826,14 +1826,6 @@
/** Stores the rendezvous descriptor version if purpose is S_*. Used to
* distinguish introduction and rendezvous points belonging to the same
* rendezvous service ID, but different descriptor versions.
- * XXXX020 I believe this is a bitmap, but the doc doesn't say so. If so,
- * why? A circuit can't be using two different rendezvous decriptors. -NM
- * Yes, it is a bitmap. The reason is that it might turn out that a version
- * 3 _can_ use the same introduction point as version 2; only version 0
- * is incompatible. Would it be clearer to switch to a single version number
- * for now and switch back to a bitmap, when the above becomes true? -KL
- * Yes. "YAGNI." -NM
- * Now it's not a bitmap any more. -KL
*/
uint8_t rend_desc_version;
Modified: tor/trunk/src/or/rendservice.c
===================================================================
--- tor/trunk/src/or/rendservice.c 2007-11-29 15:25:04 UTC (rev 12607)
+++ tor/trunk/src/or/rendservice.c 2007-11-29 15:30:32 UTC (rev 12608)
@@ -60,15 +60,7 @@
rend_service_descriptor_t *desc;
time_t desc_is_dirty;
time_t next_upload_time;
- /* XXXX020 A service never actually has both descriptor versions; perhaps
- * this should be an int rather than in intmax. */
- /* A service can never publish v0 and v2 descriptors, but maybe it can
- * publish v2 and v3 descriptors in the future. As with origin_circuit_t:
- * Would it be clearer to switch to a single version number for now and
- * switch back to a bitmap, when the above becomes true? -KL */
- /* Yes. s/when/if/. "YAGNI" -NM. */
- /* Now it's used as version number, not as bitmask. -KL */
- int descriptor_version; /**< rendezvous descriptor version that will be
+ int descriptor_version; /**< Rendezvous descriptor version that will be
* published. */
} rend_service_t;
@@ -133,7 +125,7 @@
/** Validate <b>service</b> and add it to rend_service_list if possible.
*/
static void
-add_service(rend_service_t *service)
+rend_add_service(rend_service_t *service)
{
int i;
rend_service_port_config_t *p;
@@ -163,7 +155,7 @@
v0_service->intro_exclude_nodes = tor_strdup(service->intro_exclude_nodes);
v0_service->intro_period_started = service->intro_period_started;
v0_service->descriptor_version = 0; /* Unversioned descriptor. */
- add_service(v0_service);
+ rend_add_service(v0_service);
service->descriptor_version = 2; /* Versioned descriptor. */
}
@@ -275,7 +267,7 @@
if (validate_only)
rend_service_free(service);
else
- add_service(service);
+ rend_add_service(service);
}
service = tor_malloc_zero(sizeof(rend_service_t));
service->directory = tor_strdup(line->value);
@@ -340,7 +332,7 @@
if (validate_only)
rend_service_free(service);
else
- add_service(service);
+ rend_add_service(service);
}
return 0;
Modified: tor/trunk/src/or/routerparse.c
===================================================================
--- tor/trunk/src/or/routerparse.c 2007-11-29 15:25:04 UTC (rev 12607)
+++ tor/trunk/src/or/routerparse.c 2007-11-29 15:30:32 UTC (rev 12608)
@@ -3261,10 +3261,11 @@
/* If it's <2, it shouldn't be under this format. If the number
* is greater than 2, we bumped it because we broke backward
* compatibility. See how version numbers in our other formats
- * work. */
+ * work. -NM */
/* That means that adding optional fields to the descriptor wouldn't
* require a new version number, but the way of verifying it's origin
* would. Okay. -KL */
+ /* XXX020 Nick, confirm that you're happy here -RD */
log_warn(LD_REND, "Wrong descriptor version: %d", result->version);
goto err;
}
@@ -3304,7 +3305,7 @@
smartlist_split_string(versions, tok->args[0], ",",
SPLIT_SKIP_SPACE|SPLIT_IGNORE_BLANK, 0);
for (i = 0; i < smartlist_len(versions); i++) {
- /* XXXX020 validate the numbers here. */
+ /* XXXX020 validate the numbers here. -NM */
/* As above, validating these numbers on a hidden service directory
* might require an extension to new valid numbers at some time. But
* this would require making a distinction of hidden service direcoties
@@ -3313,13 +3314,14 @@
/* As above, increased version numbers are for
* non-backward-compatible changes. This code doesn't know how to
* parse a v3 descriptor, because a v3 descriptor is by definition not
- * compatible with this code. */
+ * compatible with this code. -NM */
/* This refers to the permitted versions of introduction cells which might
* change independently from the descriptor version. If we validated the
* numbers here, a hidden service directory might reject a descriptor that
* would be understood by newer clients. Then we would need a "HSDir3" tag
* only to be able to use a new introduction cell version. I really think
* we should not validate it here. -KL */
+ /* XXX020 Nick, confirm that you're happy here -RD */
version = atoi(smartlist_get(versions, i));
result->protocols |= 1 << version;
}
@@ -3475,8 +3477,9 @@
/* Parse onion port. */
tok = find_first_by_keyword(tokens, R_IPO_ONION_PORT);
info->port = (uint16_t) atoi(tok->args[0]);
- /* XXXX020 this next check fails with ports like 65537. */
+ /* XXXX020 this next check fails with ports like 65537. -NM */
/* No, uint16_t only allows numbers in the interval 0..65535. -KL */
+ /* XXX020 Nick, confirm that you're happy here -RD */
if (!info->port) {
log_warn(LD_REND, "Introduction point onion port is out of range: %d",
info->port);
More information about the tor-commits
mailing list