|Age||Commit message (Collapse)||Author||Lines|
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
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
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
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
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
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.
the FIXME comment here was overlooked at the time locale support was
these changes are motivated by a functionally similar patch by Hauke
Mehrtens to address the needs of the new mips vdso clock_gettime,
which wrongly fails with ENOSYS rather than falling back to making a
syscall for clock ids it cannot handle from userspace. in the process
of preparing to handle that case, it was noticed that the old
clock_gettime use of the vdso was actually wrong with respect to error
handling -- the tail call to the vdso function failed to set errno and
instead returned an error code.
since tail calls to vdso are no longer possible and since the plain
syscall code is now needed as a fallback path anyway, it does not make
sense to use a function pointer to call the plain syscall code path.
instead, it's inlined at the end of the main clock_gettime function.
the new code also avoids the need to test for initialization of the
vdso function pointer by statically initializing it to a self-init
function, and eliminates redundant loads from the volatile pointer
finally, the use of a_cas_p on an object of type other than void *,
which is not permitted aliasing, is replaced by using an object with
the correct type and casting the value.
strftime results are unspecified in this case, but should not invoke
tm_wday, tm_yday, tm_mon and tm_year fields were used in signed int
arithmetic that could overflow.
based on patch by Szabolcs Nagy.
as found and reported by Brian Mastenbrook, the expressions
400*qc_cycles and years+100 in __secs_to_tm were both subject to
integer overflow for extreme values of the input t.
this patch by Szabolcs Nagy fixes the code by switching to larger
types, and matches the original intent I had in mind when writing this
The value of *size is not relevant in case of failure, but it's
better not to copy garbage from the stack into it.
(The compiler cannot see through the syscall, so optimization
was not affected by the unspecified value).
tm_gmtoff is a nonstandard field, but on historical systems which have
this field, it stores the offset of the local time zone from GMT or
UTC. this is the opposite of the POSIX extern long timezone object and
the offsets used in POSIX-form TZ strings, which represent the offset
from local time to UTC. previously we were storing these negated
offsets in tm_gmtoff too.
programs which only used this field indirectly via strftime were not
affected since strftime performed the negation for presentation.
however, some programs and libraries accesse tm_gmtoff directly and
were obtaining negated time zone offsets.
this improves compatibility with the behavior of other systems and
with some applications which set an empty TZ var to disable use of
local time by mktime, etc.
the memory model we use internally for atomics permits plain loads of
values which may be subject to concurrent modification without
requiring that a special load function be used. since a compiler is
free to make transformations that alter the number of loads or the way
in which loads are performed, the compiler is theoretically free to
break this usage. the most obvious concern is with atomic cas
constructs: something of the form tmp=*p;a_cas(p,tmp,f(tmp)); could be
transformed to a_cas(p,*p,f(*p)); where the latter is intended to show
multiple loads of *p whose resulting values might fail to be equal;
this would break the atomicity of the whole operation. but even more
fundamental breakage is possible.
with the changes being made now, objects that may be modified by
atomics are modeled as volatile, and the atomic operations performed
on them by other threads are modeled as asynchronous stores by
hardware which happens to be acting on the request of another thread.
such modeling of course does not itself address memory synchronization
between cores/cpus, but that aspect was already handled. this all
seems less than ideal, but it's the best we can do without mandating a
C11 compiler and using the C11 model for atomics.
in the case of pthread_once_t, the ABI type of the underlying object
is not volatile-qualified. so we are assuming that accessing the
object through a volatile-qualified lvalue via casts yields volatile
access semantics. the language of the C standard is somewhat unclear
on this matter, but this is an assumption the linux kernel also makes,
and seems to be the correct interpretation of the standard.
previously, the hours were considered as a signed quantity while
minutes and seconds were always treated as positive offsets. however,
semantically the '-' sign should negate the whole hh:mm:ss offset.
this bug only affected timezones east of GMT with non-whole-hours
offsets, such as those used in India and Nepal.
based on patch by Jens Gustedt for inclusion with C11 threads
implementation, but committed separately since it's independent of
this change is presently non-functional since the callees do not yet
use their locale argument for anything.
the way this is implemented, it also allows explicit setting of
TZ=/etc/localtime even for suid programs. this is not a problem
because /etc/localtime is a trusted path, much like the trusted
zoneinfo search path.