Don't infer we have a FooPort from the presence of a FooPort line

Thanks to the changes we started making with SocksPort and friends
in 0.2.3.3-alpha, any of our code that did "if (options->Sockport)"
became wrong, since "SocksPort 0" would make that test true whereas
using the default SocksPort value would make it false.  (We didn't
actually do "if (options->SockPort)" but we did have tests for
TransPort.  When we moved DirPort, ORPort, and ControlPort over to
the same system in 0.2.3.9-alpha, the problem got worse, since our
code is littered with checks for DirPort and ORPort as booleans.

This code renames the current linelist-based FooPort options to
FooPort_lines, and adds new FooPort_set options which get set at
parse-and-validate time on the or_options_t.  FooPort_set is true
iff we will actually try to open a listener of the given type. (I
renamed the FooPort options rather than leave them alone so that
every previous user of a FooPort would need to get inspected, and so
that any new code that forgetfully uses FooPort will need fail to
compile.)

Fix for bug 6507.

1 files changed, 1 insertions, 1 deletions

diff --git a/src/or/directory.c b/src/or/directory.c
index f58aab256b..40344e6b05 100644
--- a/src/or/directory.c
+++ b/src/or/directory.c
@@ -3732,7 +3732,7 @@ download_status_reset(download_status_t *dls)
   const int *schedule;
   size_t schedule_len;
 
-  find_dl_schedule_and_len(dls, get_options()->DirPort != NULL,
+  find_dl_schedule_and_len(dls, get_options()->DirPort_set,
                            &schedule, &schedule_len);
 
   dls->n_download_failures = 0;