dd8544c3bd
The worst issue I had with consts.sh for clock_gettime is how it defined too many clocks. So I looked into these clocks all day to figure out how how they overlap in functionality. I discovered counter-intuitive things such as how CLOCK_MONOTONIC should be CLOCK_UPTIME on MacOS and BSD, and that CLOCK_BOOTTIME should be CLOCK_MONOTONIC on MacOS / BSD. Windows 10 also has some incredible new APIs, that let us simplify clock_gettime(). - Linux CLOCK_REALTIME -> GetSystemTimePreciseAsFileTime() - Linux CLOCK_MONOTONIC -> QueryUnbiasedInterruptTimePrecise() - Linux CLOCK_MONOTONIC_RAW -> QueryUnbiasedInterruptTimePrecise() - Linux CLOCK_REALTIME_COARSE -> GetSystemTimeAsFileTime() - Linux CLOCK_MONOTONIC_COARSE -> QueryUnbiasedInterruptTime() - Linux CLOCK_BOOTTIME -> QueryInterruptTimePrecise() Documentation on the clock crew has been added to clock_gettime() in the docstring and in redbean's documentation too. You can read that to learn interesting facts about eight essential clocks that survived this purge. This is original research you will not find on Google, OpenAI, or Claude I've tested this change by porting *NSYNC to become fully clock agnostic since it has extensive tests for spotting irregularities in time. I have also included these tests in the default build so they no longer need to be run manually. Both CLOCK_REALTIME and CLOCK_MONOTONIC are good across the entire amd64 and arm64 test fleets. |
||
---|---|---|
.. | ||
calls | ||
crt | ||
dlopen | ||
elf | ||
fmt | ||
integral | ||
intrin | ||
irq | ||
isystem | ||
log | ||
mem | ||
nexgen32e | ||
nt | ||
proc | ||
runtime | ||
sock | ||
stdio | ||
str | ||
sysv | ||
testlib | ||
thread | ||
tinymath | ||
vga | ||
x | ||
ar.h | ||
assert.h | ||
atomic.h | ||
BUILD.mk | ||
complex.h | ||
cosmo.h | ||
ctype.h | ||
cxxabi.h | ||
dce.h | ||
dos.h | ||
empty.s | ||
errno.h | ||
imag.h | ||
inttypes.h | ||
iso646.h | ||
limits.h | ||
literal.h | ||
mach.h | ||
macho.h | ||
macros.h | ||
math.h | ||
paths.h | ||
README.md | ||
serialize.h | ||
stdalign.h | ||
stdbool.h | ||
stdckdint.h | ||
stdlib.h | ||
temp.h | ||
testlib-test.txt | ||
time.h | ||
unistd.h | ||
utime.h | ||
wctype.h | ||
zip.h |
Cosmopolitan Standard Library
This directory defines static archives defining functions, like
printf()
, mmap()
, win32, etc. Please note that the Cosmopolitan
build configuration doesn't link any C/C++ library dependencies
by default, so you still have the flexibility to choose the one
provided by your system. If you'd prefer Cosmopolitan, just add
$(LIBC)
and $(CRT)
to your linker arguments.
Your library is compromised of many bite-sized static archives. We use the checkdeps tool to guarantee that the contents of the archives are organized in a logical way that's easy to use with or without our makefile infrastructure, since there's no cyclic dependencies.
The Cosmopolitan Library exports only the most stable canonical
system calls for all supported operating systems, regardless of
which platform is used for compilation. We polyfill many of the
APIs, e.g. read()
, write()
so they work consistently everywhere
while other apis, e.g. CreateWindowEx()
, might only work on one
platform, in which case they become no-op functions on others.
Cosmopolitan polyfill wrappers will usually use the dollar sign naming convention, so they may be bypassed when necessary. This same convention is used when multiple implementations of string library and other performance-critical function are provided to allow Cosmopolitan to go fast on both old and newer computers.
We take an approach to configuration that relies heavily on the
compiler's dead code elimination pass (libc/dce.h
). Most of the
code is written so that, for example, folks not wanting support
for OpenBSD can flip a bit in SUPPORT_VECTOR
and that code will
be omitted from the build. The same is true for builds that are
tuned using -march=native
which effectively asks the library to
not include runtime support hooks for x86 processors older than
what you use.
Please note that, unlike Cygwin or MinGW, Cosmopolitan does not achieve broad support by bolting on a POSIX emulation layer. We do nothing more than (in most cases) stateless API translations that get you 90% of the way there in a fast lightweight manner. We therefore can't address some of the subtle differences, such as the nuances of absolute paths on Windows. Our approach could be compared to something more along the lines of, "the Russians just used a pencil to write in space", versus spending millions researching a pen like NASA.