If a file doesn't use the file command (either \file or @file),
Doxygen won't try to process it.
These declarations also turned up a doxygen warning for
crypto_ope.c; I fixed that too.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
confparse.h confmgt.h \
confparse.c confmgt.c \
CONFPARSE_PRIVATE CONFMGT_PRIVATE \
TOR_CONFPARSE_H TOR_CONFMGT_H
Unlike legacy_validate_fn_t, these callbacks have separation of
duties, into:
* early normalization and computation.
* validation
* transition checking
* late normalization and computation
Only the first and last steps get mutable objects. Only the
transition-checking step gets to see the previous values of this
object.
The former foo_validate() functions are now toplevel
legacy_validate_fn callbacks. The new foo_validate() functions now
call them.
This change lets us remove the old shared_random disk state
validation callback entirely.
As we turn our monolithic configuration objects into suites of
smaller module-specific configuration objects, we will want each one
to be able to provide its own verification callbacks. That means
that instead of invoking these verification callbacks directly, we will
want to call them via the configuration manager object.
The current API of this callback mixes responsibilities, including:
* validation
* transition checking
* processing (modifying) the configuration object.
These will have to be disentangled piece by piece, so for now, we'll
have "legacy" validate functions as well.
This is an automated commit, generated by this command:
./scripts/maint/rename_c_identifier.py \
validate_fn_t legacy_validate_fn_t \
validate_fn legacy_validate_fn
Conflicts:
src/feature/dirparse/authcert_parse.c
src/feature/dirparse/ns_parse.c
src/feature/hs/hs_service.c
src/lib/conf/conftesting.h
src/lib/log/log.h
src/lib/thread/threads.h
src/test/test_options.c
These conflicts were mostly related to autostyle improvements, with
one or two due to doxygen fixes.
This patch fixes an issue where the exit handler is not called for the
given process_t in case CreateProcessA() fails. This could, for example,
happen if the user tries to execute a binary that does not exist.
See: https://bugs.torproject.org/31810
This patch removes a call to tor_assert_unreached() after execve()
failed. This assertion leads to the child process emitting a stack trace
on its standard output, which makes the error harder for the user to
demystify, since they think it is an internal error in Tor instead of
"just" being a "no such file or directory" error.
The process will now instead output "Error from child process: X" where
X is the stringified version of the errno value.
See: https://bugs.torproject.org/31810
We used to have this function so that we could mark our initial
log-to-stdout as specifically temporary so that we would delete it
once regular logs were configured. But it's no longer necessary to
mark these logs as temporary, since we now use a mark-and-sweep
process to ensure that _all_ not-configured logs are closed when we
change our configuration.
Instead, this function will be the basis of a refactoring in how we
handle default logs.
In case of error, a negative value will be returned or NULL written into
first supplied argument.
This patch uses both cases to comply with style in the specific files.
A tor_vasprintf error in process_vprintf would lead to a NULL dereference
later on in buf_add, because the return value -1 casted to size_t would
pass an assertion check inside of buf_add.
On the other hand, common systems will fail on such an operation, so it
is not a huge difference to a simple assertion. Yet it is better to
properly fail instead of relying on such behaviour on all systems.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Nick Mathewson
teor
David Goulet
AmreshVenugopal
Alexander Færøy
Tobias Stoeckmann