[tor-bugs] #29209 [Core Tor/Tor]: Reduce visibility of more data type internals
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Apr 18 10:15:59 UTC 2019
#29209: Reduce visibility of more data type internals
----------------------------------------+----------------------------------
Reporter: nickm | Owner: (none)
Type: task | Status: needs_review
Priority: Medium | Milestone: Tor:
| 0.4.1.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: technical-debt refactoring | Actual Points: 3.5
Parent ID: | Points: 15
Reviewer: nickm | Sponsor: Sponsor31-can
----------------------------------------+----------------------------------
Comment (by asn):
I opened #30236 for the crypt_path case.
I agree that the private approach I took is suboptimal. Here are some
thoughts about the options above:
- Option1: I find usin the downcast approach a bit of an overkill here,
but it might be the right way forward.
- Option2: I think I like this, it seems quite simple. The only negative
is that there is no warning if someone uses the private field outside of a
private file, but I don't think people will attempt to do that with that
name and macro (and appropriate docs).
- Option3: I don't think I like this because `#define b PRIV(b)` might
hijack lots of stuff. So for example, in the crypt_path_t.crypto case we
would have to do `#define crypto PRIV(crypto)` and that would hijack all
the cryptos in the file. Also it would be bad form to not capitalize
`crypto` in that case, and ugly if we did.
- Option4: This also seems like a plausible one. I'm not sure what `pvt`
is there tho. I like the fact that it throws a message.
I think right now I'm leaning more towards option2 for being the most
lightweight one and easy to understand. What do you think?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29209#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list