[tor-bugs] #29209 [Core Tor/Tor]: Reduce visibility of more data type internals

[Tor Bug Tracker & Wiki]

#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