strptime(3) doesn't set errno, so when it was failing, calling perror()
meant producing messages like:
Failed to parse FAKETIME timestamp: Success
Rather than use perror(), just send the warning message directly to
stderr.
This was first reported in https://bugs.debian.org/939789
Using this structure makes diffs easier to read, when changes are due.
The underlying formatting produced by groff ends up basically the same
(though some versions of groff may adjust to have two spaces after a
sentence-ending period instead of one).
the newer version gcc warns `this ‘while’ clause does not guard... [-Werror=misleading-indentation]`. looks like the author just omitted the `do` and the `while(0) counts as a separate statement.
in practice this isn't causing any actual problem now afaict.
Specifically behaviors that increase the chance that a wrapped program
will not behave like an unwrapped program does, thus causing
reliability issues.
The test suite should not succeed if INTERCEPT_SYSCALL is defined but
the variadic argument promotion test fails.
OTOH, if we're not asking for INTERCEPT_SYSCALL, we don't care about
the results of that test.
This test uses the same style of re-packing variadic arguments through
two layers of variadic calls, and compares that call chain against one
direct variadic call.
The outer function uses the same kind of re-packing used in
src/libfaketime.c's syscall (leading to real_syscall), but the inner
functions use different assumptions about the types of each argument.
This is not an entirely comprehensive test, because we only define two
different inner function signatures. If some particular syscall is
breaking when intercepted, consider adding something like its expected
function signature in test/variadic/inner.c, and invoke it in
test/variadic/main.c.
Note that we don't test any floating point types (those types are
typically passed in registers in x86-64, not on the stack, and are
also not used for any syscall that i'm aware of).
If FAKERANDOM is unset, we were still intercepting syscall() and
passing it through to clock_gettime, rather than letting it fall
through to real_syscall.
That would have the effect of diverting syscall(__NR_clock_gettime,…)
into the libc invocation of clock_gettime(…) (via real_clock_gettime).
While that probably does the same thing, it's probably a mistake to do
such a diversion when FAKETIME is unset.
This invokes clock_gettime, but uses a timespec from the heap instead
of the stack.
It appears to be successful for me on x86-64 GNU/Linux.
This rules out one possible cause of the error reported in #310: I was
worried that an address from the range occupied by the heap might
somehow be corrupted by the syscall variadic argument de-mangling, but
that looks like it is not the case.
