[tor-bugs] #20168 [Core Tor/Tor]: Clarify our #if{n}def by commenting what they are at the #elif/#else/#endif
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Sep 12 14:33:13 UTC 2017
#20168: Clarify our #if{n}def by commenting what they are at the #elif/#else/#endif
------------------------------------------+--------------------------------
Reporter: dgoulet | Owner: cjb
Type: enhancement | Status: merge_ready
Priority: Very Low | Milestone: Tor:
| 0.3.2.x-final
Component: Core Tor/Tor | Version:
Severity: Trivial | Resolution:
Keywords: easy, lorax, review-group-23 | Actual Points: .1
Parent ID: | Points:
Reviewer: dgoulet | Sponsor:
------------------------------------------+--------------------------------
Changes (by dgoulet):
* status: needs_revision => merge_ready
* reviewer: => dgoulet
Comment:
Replying to [comment:24 nickm]:
> We can do `/* ... */`, and I tried that at first, but it will make a lot
more lines that are longer than 80 columns and need to get truncated.
Still want it?
I made a test, I see 10 long line with `//` and 17 with `/* */`. I even
volunteer to fix those after merge :P.
>
> I think the issue you're reporting with statefile.h is not about outer
vs inner, but about the rule that we don't annotate endifs that are within
4 lines of their ifs. (See `LINE_OBVIOUSNESS_LIMIT` in the script.)
Ok! Didn't catch that.
I found another "issue" in `src/ext/OpenBSD_malloc_Linux.c`:
`#else // !(!defined(BUILDING_FOR_TOR))` ... which seems odd. Maybe the
script is confused by the #define at the start of the file and then
`#ifndef` later ?
I mean "double negative" is right just kind of harder to parse. If it is
an easy fix to detect double negative to be just "defined()", great else
no biggy. Anyway, I'm being picky here just for documentation :P.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20168#comment:25>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list