-
- Downloads
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.
Showing
- changes/bug6507 7 additions, 0 deletionschanges/bug6507
- src/or/config.c 84 additions, 43 deletionssrc/or/config.c
- src/or/directory.c 1 addition, 1 deletionsrc/or/directory.c
- src/or/directory.h 1 addition, 1 deletionsrc/or/directory.h
- src/or/dirserv.c 6 additions, 6 deletionssrc/or/dirserv.c
- src/or/or.h 26 additions, 7 deletionssrc/or/or.h
- src/or/router.c 3 additions, 2 deletionssrc/or/router.c
- src/or/routerparse.c 1 addition, 1 deletionsrc/or/routerparse.c
Loading
Please register or sign in to comment