clean up the XXX comments around bug 1038

src/or/command.c

@@ -395,8 +395,10 @@ command_process_relay_cell(cell_t *cell, or_connection_t *conn)
    * gotten no more than MAX_RELAY_EARLY_CELLS_PER_CIRCUIT of them. */
   if (cell->command == CELL_RELAY_EARLY) {
     if (direction == CELL_DIRECTION_IN) {
-      /* XXX Allow an unlimited number of inbound relay_early cells for
-       * now, for hidden service compatibility. See bug 1038. -RD */
+      /* Allow an unlimited number of inbound relay_early cells,
+       * for hidden service compatibility. There isn't any way to make
+       * a long circuit through inbound relay_early cells anyway. See
+       * bug 1038. -RD */
     } else {
       or_circuit_t *or_circ = TO_OR_CIRCUIT(circ);
       if (or_circ->remaining_relay_early_cells == 0) {

src/or/relay.c

@@ -556,9 +556,9 @@ relay_send_command_from_edge(uint16_t stream_id, circuit_t *circ,
        * Don't worry about the conn protocol version:
        * append_cell_to_circuit_queue will fix it up. */
       /* XXX For now, clients don't use RELAY_EARLY cells when sending
-       * relay cells on rendezvous circuits. See bug 1038. Eventually,
-       * we can take this behavior away in favor of having clients avoid
-       * rendezvous points running 0.2.1.3-alpha through 0.2.1.18. -RD */
+       * relay cells on rendezvous circuits. See bug 1038. Once no relays
+       * (and thus no rendezvous points) are running 0.2.1.3-alpha through
+       * 0.2.1.18, we can take out that exception. -RD */
       cell.command = CELL_RELAY_EARLY;
       --origin_circ->remaining_relay_early_cells;
       log_debug(LD_OR, "Sending a RELAY_EARLY cell; %d remaining.",