#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):
Replying to [comment:9 nickm]:
> Here is an alternative approach I talked about with Catalyst:
> {{{
> // Option 5
> struct foobar_t {
> int a;
> char *_modulename__private__b;
> long c;
> };
>
> #ifdef MODULENAME_PRIVATE
> #define my_b _modulename__private_b
> #endif
> }}}
> Instead of my_b we might use private_b, pvt_b, local_b, or something.
That seems similar to option #3 from above.
So to understand this better. How would that look for the patch in #30236?
Would we have to turn `crypto` into `my_crypto` when `PRIVATE` is set? I
think turning it into `pvt_crypto` or `local_crypto` might even be
ambiguous in terms of cryptography. `my_crypto` can also be a bit
ambiguous but let's ignore this for now.
Also, is it fine to have a macro definition be named in lowercase? Could
this be confusing?
If we are fine with the above, that seems like a plausible way to go
forward and I can change my patch for #30236.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29209#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
