Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:48:28Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32581Turn on clang's -Wtype-safety to detect fnctl() and ioctl() errors2020-06-13T15:48:28ZteorTurn on clang's -Wtype-safety to detect fnctl() and ioctl() errorsSee:
https://clang.llvm.org/docs/AttributeReference.html#type-safety-checkingSee:
https://clang.llvm.org/docs/AttributeReference.html#type-safety-checkingTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32580Use clang's enum_extensibility attribute to check enum values2020-06-13T15:48:28ZteorUse clang's enum_extensibility attribute to check enum valuesWe could avoid constructing bad enum values using enum_extensibility:
https://clang.llvm.org/docs/AttributeReference.html#enum-extensibilityWe could avoid constructing bad enum values using enum_extensibility:
https://clang.llvm.org/docs/AttributeReference.html#enum-extensibilityTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32579Use clang's -Wimplicit-fallthrough and fallthrough attribute on case statements2020-06-13T15:48:28ZteorUse clang's -Wimplicit-fallthrough and fallthrough attribute on case statementsWe can avoid accidental fallthroughs using clang's -Wimplicit-fallthrough.
https://clang.llvm.org/docs/AttributeReference.html#fallthroughWe can avoid accidental fallthroughs using clang's -Wimplicit-fallthrough.
https://clang.llvm.org/docs/AttributeReference.html#fallthroughTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24490Stop setting bridges running in networkstatus_getinfo_by_purpose()2020-06-13T15:41:02ZteorStop setting bridges running in networkstatus_getinfo_by_purpose()A GETINFO controller function shouldn't modify vital data structures.
Instead, we should make sure the list is up to date regularly, or that it is updated before we call this function.
This bug was introduced in commit 74d05f4 in tor-0...A GETINFO controller function shouldn't modify vital data structures.
Instead, we should make sure the list is up to date regularly, or that it is updated before we call this function.
This bug was introduced in commit 74d05f4 in tor-0.2.0.13-alpha.Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24489Add some consts to networkstatus_getinfo_by_purpose()2020-06-13T15:18:18ZteorAdd some consts to networkstatus_getinfo_by_purpose()We shouldn't modify any of the data structures passed to networkstatus_getinfo_by_purpose(). But the current design modifies the running flag in the GETINFO.
The patch I'm about to post makes sure we don't accidentally modify any more o...We shouldn't modify any of the data structures passed to networkstatus_getinfo_by_purpose(). But the current design modifies the running flag in the GETINFO.
The patch I'm about to post makes sure we don't accidentally modify any more of the data structures.
Thanks to komlo - the patch was her idea, and she helped create it.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/24488Make set_routerstatus_from_routerinfo() set IPv6 unspecified addresses2020-06-13T15:18:17ZteorMake set_routerstatus_from_routerinfo() set IPv6 unspecified addressesset_routerstatus_from_routerinfo() currently sets ipv6_orport to all zeroes. But it should be set to the unspecified IPv6 address.
This is unlikely to cause any bugs in previous Tor versions, but we should fix this for correctness.
Thi...set_routerstatus_from_routerinfo() currently sets ipv6_orport to all zeroes. But it should be set to the unspecified IPv6 address.
This is unlikely to cause any bugs in previous Tor versions, but we should fix this for correctness.
This is a bug on commit 6d99c51 in 0.2.4.1-alpha.Tor: 0.3.3.x-finalteorteor