A single program that invokes getrandom() repeatedly should end up
with the same stream of bytes, regardless of how it chunks up the
reading from the entropy source.
This test already passses. I'm including it because it seems
like a useful confirmation.
In some configurations, GNU make might treat librandom.so as an
ephemeral/intermediate build artifact and destroy it before
randomtest.sh is run. This ensures the shared object is present when
needed.
This avoids potential failure if another library calls getrandom()
within its constructor before we are loaded.
For me, it lets "make randomtest" succeed in tests/
Closes: #295
Previously, we had failed to test code with getrandom() against
LD_PRELOAD when FAKERANDOM_SEED was unset.
We also want to try calling getrandom twice in a single process to
make sure that works OK.
In trying to test the experimental getrandom features, I found a few
minor problems. These changes should make it easier to test.
After building, the developer can now just do:
make -C test randomtest
This will do a basic verfication that the feature works as expected.
I haven't tried to integrate this with the overall "make test". To do
that right, it should condition the test on the definition of
FAKE_RANDOM.
Without this fix, when compiling with `-O1` or more, we see:
```
libfaketime.c: In function ‘fake_clock_gettime’:
libfaketime.c:2843:7: error: variable ‘ret’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
2843 | int ret = INT_MAX;
| ^~~
cc1: all warnings being treated as errors
```
This error doesn't happen when using `-O0`.
The warning appears to happen when the compiler optimizes `ret`
because it is the return value for the function call (meaning maybe
preserved in a register, or some other more risky placement that might
break during the `goto` error cases?). Explicitly marking it as
volatile should keep the compiler from optimizing that way, regardless
of the level of optimization the user asks for.
I got the idea to use `volatile` here from the rather confused
discussion in
https://cboard.cprogramming.com/c-programming/147829-help-me-warning-argument-fmtstring-might-clobbered-longjmp-vfork.html
I admit I don't fully understand what's going on here, and would be
grateful for review by someone who understands the machinery here at a
deeper level than I do.
- Fix the utime() and utimes() functions to work with a NULL arg
(which is a request for "now").
- Add missing utimensat() & futimens() functions.
- Add support for a FAKE_UTIME define and enable it by default. This
is like defining FAKE_FILE_TIMESTAMPS except that the code defaults
to NO utime faking unless FAKE_UTIME environment var enables it.
- When utime values are not being faked, the use of a NULL arg or a
UTIME_NOW nsec value gives the user NOW translated into their fake
current time. This is because the caller's fake times are otherwise
being preserved, so we should help their NOW request also be handled
as a fake time.
- Mention FAKE_FILE_TIMESTAMPS & FAKE_UTIME in the src/Makefile.
- Move a sanity check in fake_clock_gettime() to where it is actually
prior to all the pointer dereferences it should protect.
- Get rid of an errant tab in the src/Makefile's comments.
On Ubuntu 20.04 using gcc 9.3, make test fails due to a deprecated
function (ftime) warning in combination with -Werror in timetest.c.
Since the warning is from a test testing that the deprecated function
can be replaced using LD_PRELOAD, I think it's reasonable to just
silence the warning in that case.
When the environment variable FAKETIME_TIMESTAMP_FILE is set, points to
a writeable (creatable) custom config file and the environment variable
FAKETIME_UPDATE_TIMESTAMP_FILE is "1", then the file also is updated on
each call. By this, a common "virtual time" can be shared by several
processes, where each can adjust the time for all.
