| Age | Commit message (Collapse) | Author | Lines |
|---|
|
POSIX allows a null pointer, in which case the function only checks
the validity of the clock id argument.
|
|
at the point of this check, the pointer has already been dereferenced.
clock_settime is not defined for null pointer arguments.
|
|
commit 72f50245d018af0c31b38dec83c557a4e5dd1ea8 broke this by creating
a code path where r is uninitialized.
|
|
this fixes a major upcoming performance regression introduced by
commit 72f50245d018af0c31b38dec83c557a4e5dd1ea8, whereby 32-bit archs
would lose vdso clock_gettime after switching to 64-bit time_t, unless
the kernel supports time64 and provides a time64 version of the vdso
function. this would incur not just one but two syscalls: first, the
failed time64 syscall, then the fallback time32 one.
overflow of the 32-bit result is detected and triggers a revert to
syscalls. normally, on a system that's not Y2038-ready, this would
still overflow, but if the process has been migrated to a
time64-capable kernel or if the kernel has been hot-patched to add
time64 syscalls, it may conceivably work.
|
|
the time64 syscall has to be used if time_t is 64-bit, since there's
no way of knowing before making a syscall whether the result will fit
in 32 bits, and the 32-bit syscalls do not report overflow as an
error.
on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the result is now read from the kernel
through long[2] array, then copied into the timespec, to remove the
assumption that time_t is the same as long.
vdso clock_gettime is still used in place of a syscall if available.
32-bit archs with 64-bit time_t must use the time64 version of the
vdso function; if it's not available, performance will significantly
suffer. support for both vdso functions could be added, but would
break the ability to move a long-lived process from a pre-time64
kernel to one that can outlast Y2038 with checkpoint/resume, at least
without added hacks to identify that the 32-bit function is no longer
usable and stop using it (e.g. by seeing negative tv_sec). this
possibility may be explored in future work on the function.
|
|
the time64 syscall for this is not necessary or useful, since clock
resolution is generally better than 68-year granularity. if there's a
32-bit syscall, use it and expand the result into timespec; otherwise
there is only one syscall and it does the right thing to store to
timespec directly.
on 64-bit archs, there is no change to the code after preprocessing.
|
|
the time64 syscall has to be used if time_t is 64-bit, since there's
no way of knowing before making a syscall whether the result will fit
in 32 bits, and the 32-bit syscalls do not report overflow as an
error.
on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the result is now read from the kernel
through long[4] array, then copied into the timespec, to remove the
assumption that time_t is the same as long.
|
|
time64 syscall is used only if it's the only one defined for the arch,
or if the requested time does not fit in 32 bits. on current 32-bit
archs where time_t is a 32-bit type, this makes it statically
unreachable.
if the time64 syscall is needed because the requested time does not
fit in 32 bits, we define this as an error ENOTSUP, for "The
implementation does not support the requested feature or value".
on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the time is moved through an intermediate
copy to remove the assumption that time_t is a 32-bit type.
|
|
time64 syscall is used only if it's the only one defined for the arch,
if either component of the itimerspec does not fit in 32 bits, or if
time_t is 64-bit and the caller requested the old value, in which case
there's a possibility that the old value might not fit in 32 bits. on
current 32-bit archs where time_t is a 32-bit type, this makes it
statically unreachable.
on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the time is moved through an intermediate
copy to remove the assumption that time_t is a 32-bit type.
|
|
time64 syscall is used only if it's the only one defined for the arch,
or if the requested time does not fit in 32 bits. on current 32-bit
archs where time_t is a 32-bit type, this makes it statically
unreachable.
on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the time is moved through an intermediate
copy to remove the assumption that time_t is a 32-bit type.
|
|
for namespace-safety with thrd_sleep, this requires an alias, which is
also added. this eliminates all but one direct call point for
nanosleep syscalls, and arranges that 64-bit time_t conversion logic
will only need to exist in one file rather than three.
as a bonus, clock_nanosleep with CLOCK_REALTIME and empty flags is now
implemented as SYS_nanosleep, thereby working on older kernels that
may lack POSIX clocks functionality.
|
|
whether signals need to be blocked at thread start, and whether
unblocking is necessary in the entry point function, has historically
depended on intricacies of the cancellation design and on whether
there are scheduling operations to perform on the new thread before
its successful creation can be committed. future changes to track an
AS-safe list of live threads will require signals to be blocked
whenever changes are made to the list, so ...
prior to commits b8742f32602add243ee2ce74d804015463726899 and
40bae2d32fd6f3ffea437fa745ad38a1fe77b27e, a signal mask for the entry
function to restore was part of the pthread structure. it was removed
to trim down the size of the structure, which both saved a small
amount of stack space and improved code generation on archs where
small immediate displacements are less costly than arbitrary ones, by
limiting the range of offsets between the base of the thread
structure, its members, and the thread pointer. these commits moved
the saved mask to a special structure used only when special
scheduling was needed, in which case the pthread_create caller and new
thread had to synchronize with each other and could use this memory to
pass a mask.
this commit partially reverts the above two commits, but instead of
putting the mask back in the pthread structure, it moves all "start
argument" members out of the pthread structure, trimming it down
further, and puts them in a separate structure passed on the new
thread's stack. the code path for explicit scheduling of the new
thread is also changed to synchronize with the calling thread in such
a way to avoid spurious futex wakes.
|
|
this eliminates some ugly hacks that were repurposing the start
function and start argument fields in the pthread structure for timer
use, and the need to longjmp out of a signal handler.
|
|
commit a6054e3c94aa0491d7366e4b05ae0d73f661bfe2 removed the argument,
making it a constraint violation to pass one. caught by cparser/firm;
other compilers seem to ignore it.
|
|
a caller needs the reason for open (or fstat, albeit unlikely) failure
if it's going to make decisions about continuing a path search or
similar.
|
|
do_tzset() did't always reset the DST transition rules r0 and r1. That
means the rules from older TZ settings could leak into newer ones.
|
|
this further reduces the number of source files which need to include
libc.h and thereby be potentially exposed to libc global state and
internals.
this will also facilitate further improvements like adding an inline
fast-path, if we want to do so later.
|
|
libc.h was intended to be a header for access to global libc state and
related interfaces, but ended up included all over the place because
it was the way to get the weak_alias macro. most of the inclusions
removed here are places where weak_alias was needed. a few were
recently introduced for hidden. some go all the way back to when
libc.h defined CANCELPT_BEGIN and _END, and all (wrongly implemented)
cancellation points had to include it.
remaining spurious users are mostly callers of the LOCK/UNLOCK macros
and files that use the LFS64 macro to define the awful *64 aliases.
in a few places, new inclusion of libc.h is added because several
internal headers no longer implicitly include libc.h.
declarations for __lockfile and __unlockfile are moved from libc.h to
stdio_impl.h so that the latter does not need libc.h. putting them in
libc.h made no sense at all, since the macros in stdio_impl.h are
needed to use them correctly anyway.
|
|
|
|
|
|
|
|
commits leading up to this one have moved the vast majority of
libc-internal interface declarations to appropriate internal headers,
allowing them to be type-checked and setting the stage to limit their
visibility. the ones that have not yet been moved are mostly
namespace-protected aliases for standard/public interfaces, which
exist to facilitate implementing plain C functions in terms of POSIX
functionality, or C or POSIX functionality in terms of extensions that
are not standardized. some don't quite fit this description, but are
"internally public" interfacs between subsystems of libc.
rather than create a number of newly-named headers to declare these
functions, and having to add explicit include directives for them to
every source file where they're needed, I have introduced a method of
wrapping the corresponding public headers.
parallel to the public headers in $(srcdir)/include, we now have
wrappers in $(srcdir)/src/include that come earlier in the include
path order. they include the public header they're wrapping, then add
declarations for namespace-protected versions of the same interfaces
and any "internally public" interfaces for the subsystem they
correspond to.
along these lines, the wrapper for features.h is now responsible for
the definition of the hidden, weak, and weak_alias macros. this means
source files will no longer need to include any special headers to
access these features.
over time, it is my expectation that the scope of what is "internally
public" will expand, reducing the number of source files which need to
include *_impl.h and related headers down to those which are actually
implementing the corresponding subsystems, not just using them.
|
|
it's already included in all places where these are needed, and aside
from __tls_get_addr, they're all implementation internals.
|
|
this is a helper function from strftime that's also used by wcsftime.
|
|
this function was added later for strftime use and the existence of
time_impl.h as the appropriate place for it seems to have been
overlooked.
|
|
obviously the type "should be" const, but it inherited non-const from
the standard nl_langinfo_l.
|
|
get rid of a gratuitous translation unit and call frame between
asctime_r and the actual implementation of the function. this is the
way gmtime_r and localtime_r are already done.
|
|
|
|
This manifests itself in mktime if tm_isdst = 1 and the current TZ= is
a POSIX timezone specification. mktime would see that tm_isdst was set
to 0 by __secs_to_zone, and subtract 'oppoff' (dst_off) - gmtoff from
the resultant time. This meant that mktime returned a time that was
exactly double the GMT offset of the desired timezone when tm_isdst
was = 1.
|
|
the sign character produced came from the sign of tm_gmtoff/3600 as an
integer division, which is zero for negative offsets smaller in
magnitude than 3600. instead of printing the hours and minutes as
separate fields, print them as a single value of the form
hours*100+minutes, which naturally has the correct sign.
|
|
the expression (tm->__tm_gmtoff)/3600 has type long. use %+.2ld instead.
|
|
Commit 8a6bd7307da3fc4d08dd6a9277b611ccb4971354 added support for
padding specifier extensions to strftime, but did not modify wcsftime.
In the process, it added a parameter to __strftime_fmt_1 in strftime.c,
but failed to update the prototype in wcsftime.c. This was found by
compiling musl with LTO:
src/time/wcsftime.c:7:13: warning: type of '__strftime_fmt_1' does \
not match original declaration [-Wlto-type-mismatch]
Fix the prototype of __strftime_fmt_1 in wcsftime.c, and generate the
'pad' argument the same way as it is done in strftime.
|
|
it's unclear from the specification whether the word "consumes" in
"consumes more than four bytes to represent a year" refers just to
significant places or includes leading zeros due to field width
padding. however the examples in the rationale indicate that the
latter was the intent. in particular, the year 270 is shown being
formatted by %+5Y as +0270 rather than 00270.
previously '+' prefixing was implemented just by comparing the year
against 10000. instead, count the number of significant digits and
padding bytes to be added, and use the total to determine whether to
apply the '+' prefix.
based on testing by Dennis Wölfing.
|
|
the code to strip initial sign and leading zeros inadvertently
stripped all the zeros and the subsequent '-' separating the month.
instead, only strip sign characters from the very first position, and
only strip zeros when they are followed by another digit.
based on testing by Dennis Wölfing.
|
|
In all cases this is just a change from two volatile int to one.
|
|
notes by maintainer:
both C and POSIX use the term UTC to specify related functionality,
despite POSIX defining it as something more like UT1 or historical
(pre-UTC) GMT without leap seconds. neither specifies the associated
string for %Z. old choice of "GMT" violated principle of least
surprise for users and some applications/tests. use "UTC" instead.
|
|
notes added by maintainer:
the '-' specifier allows default padding to be suppressed, and '_'
allows padding with spaces instead of the default (zeros).
these extensions seem to be included in several other implementations
including FreeBSD and derivatives, and Solaris. while portable
software should not depend on them, time format strings are often
exposed to the user for configurable time display. reportedly some
python programs also use and depend on them.
|
|
commit a6054e3c94aa0491d7366e4b05ae0d73f661bfe2 changed this function
not to take an argument, but the weak definition used by timer_create
was not updated to match.
reported by Pascal Cuoq.
|
|
POSIX requires ctime_r return a null pointer on failure, which can
occur if the input time_t value is not representable in broken down
form.
based on patch by Alexander Monakov.
|
|
ctime passes the result from localtime directly to asctime. But in case
of error, localtime returns 0. This causes an error (NULL pointer
dereference) in asctime.
based on patch by Omer Anson.
|
|
POSIX defines getdate error #5 as:
"An I/O error is encountered while reading the template file."
POSIX defines getdate error #7 as:
"There is no line in the template that matches the input."
This change correctly disambiguates between the two error conditions.
|
|
in this case, a potentially-uninitialized or unrelated existing value
in tm_year was being used. instead use 0 if %y was not present.
|
|
string pointer was not advanced after matching.
|
|
tm_yday range is 0-365 while %j is 1-366
|
|
the time of day at which daylight time switches over is specified in
local time in the dst state prior to the transition. the code for
handling this wrongly assumed it needed to switch whether dst or
standard offset is applied to the transition time when the dst end
date is before the dst start date (souther hemisphere summer), but in
fact the end transition time should always be adjusted for dst, and
the start transition time should always be adjusted for standard time.
|
|
commit 583ea83541dcc6481c7a1bd1a9b485526bad84a1 fixed the case where
tm_year is negative but the resulting year (offset by 1900) was still
positive, which is always the case for time_t values that fit in 32
bits, but not for arbitrary inputs.
based on an earlier patch by Julien Ramseier which was overlooked at
the time the previous fix was applied.
|
|
the overflow check for years+100 did not account for the extra
year computed from the remaining months. instead, perform this
check after obtaining the final number of years.
|
|
Fix parsing of the < > quoted time zone names. Compare the correct
character instead of repeatedly comparing the first character.
|
|
accessing an object of type const char *restrict as if it had type
char * is not defined.
|
|
posix requires that EINVAL be returned if the first parameter specifies
the cpu-time clock of the calling thread (CLOCK_THREAD_CPUTIME_ID).
linux returns ENOTSUP instead so we handle this.
|
