These changes conforms to the C11 standard
References:
- 7.27.1/3 Components of time (struct timespec)
- 7.27.2.5 The timespec_get function
According to ISO/IEC 9899:201x (draft) <time.h> defines the timespec
structure and declares the timespec_get(3) function with TIME_UTC
definition.
According to a C++17 standard draft <ctime> offers the same interface in
the std:: namespace.
The timespec_get function modifies the timespec object pointed by ts
to hold the current calendar time in the given base. The standard notes
only the TIME_UTC base with implementation defined value, set it to 1
as zero is reserved for error handling. Once operation was successful this
function returns passed base, otherwise exits with zero.
The timespec struct was already part of the POSIX standard in <time.h>.
Enable this interface unconditionally in the header to allow to use it
in a code prior C11 and C++17 as an extension.
Review notes from <christos>
Also make the tracefile customizable. Unfortunately we can't merge any of
the hash changes because they have a different on-disk format. That does not
matter really because we've fixed most of the problems...
/usr/tests/lib/libc/sys/t_getcontext
/usr/tests/lib/libc/sys/t_swapcontext
/usr/tests/lib/libc/sys/t_ucontext
/usr/tests/lib/libpthread/t_swapcontext
All pass now.
Changes amount to
- saving GP from caller in context for n{32,64}
- performing (the equivalient of) PIC_PROLOGUE for swapcontext and
__resumecontext
- Call setcontext via the PLT in __resumecontext
behavior and when new memory is zeroed.
Also, strengthen the warning about mixing with calls to malloc (which
is not a bug) and mention that the portable way to fetch the initial
break is to call sbrk(0). There are implementations in the wild where
using _end as the initial break doesn't work.
1) Set the stdio error indicator on __slbexpand() failure.
2) fgetwc(3) may succeed even when ferror(3) is already set
(for example, consider a program using SIG_IGN on SIGTTIN,
reading from the tty while in the background, getting EIO,
then coming to the foreground and reading again).
So do not force fgetwln(3) to fail in such a case either.
(Yes, the program should probably clearerr(3) before
reading again, but let's be nicer in case it forgets.)
