Our line limit is 80 characters, assuming that there is a single
terminating newline character that counts towards the limit. On
Windows, this might go as high as 81 characters, if we count CRLF as
two characters.
This change should reduce the number of cases where we say
"/* !(!defined(foo)) */" .
This only does cases where we can use a regex to make sure that the
simplification is guaranteed to be correct. Full boolean
simplification would require this script to parse C, and nobody
wants that.
- The function `decrypt_desc_layer` has a cleaner interface.
- `is_superencrypted_layer` changed from `int` -> `bool`
[ticket details](https://trac.torproject.org/projects/tor/ticket/31589)
add(changes/*): changes file
fix(src/features/hs): is_superencrypted changed from `int` -> `bool`
fix(changes/ticket31589): header
add(changes/ticket31589): subsystem(onion services) to change
If we would add a comment making a line longer than 80 columns,
instead truncate the variable portion of the comment until it just
fits into 80 columns, with an ellipsis.
We want to forbid this pattern since, unlike the other log_*()
macros, log_debug() conditionally evaluates its arguments only if
debug-level logging is enabled. Thus, a call to
log_debug("%d", x++);
will only increment x if debugging logs are enabled, which is
probably not what the programmer intended.
One bug caused by this pattern was #30628.
This script detects log_debug( ) calls with any of E++, E--, ++E,
or --E in their arguments, where E is an arbitrary expression.
Closes ticket 30743.
The purpose of tracking whether an exception is used is so that we
can tell whether it is overbroad. This means that an _underbroad_
exception is still a used one. Fixes bug 31338.
Note that this header file behaves a bit strangely. It is used by
coccinelle just for the purpose of knowing how to parse
difficult-to-parse stuff. It doesn't need to produce good C -- just
grammatical C.
spatch can let us know whether a file has parsed "perfectly" or
not. The more perfect it parses, the likelier any semantic patches
are to apply. I've used this script to identify problem areas in
our code.
It's a bit tricky to remember the right incantation to get the
proper include paths and incantations for coccinelle, but without
it, coccinelle is less effective at parsing our C.