Currently, in cosmopolitan, there is no handling of the current rounding mode for long double conversions, such that round-to-nearest gets always used, regardless of the current rounding mode. %Le also improperly calls gdtoa with a too small precision (which led to relatively similar bugs). This patch fixes these issues, in particular by modifying the FPI object passed to gdtoa such that it is modifiable (so that __fmt can adjust its rounding field to correspond to FLT_ROUNDS (note that this is not needed for dtoa, which checks FLT_ROUNDS directly)) and ors STRTOG_Neg into the kind field in both of the __fmt_dfpbits and __fmt_ldfpbits functions, as the gdtoa function also depends on it to be able to accurately round any negative arguments. The change to kind also requires a few other changes to make sure kind's upper bits (which include STRTOG_Neg) are masked off when attempting to only examine the lower bits' value. Furthermore, this patch also makes exactly one change in gdtoa, which appears to be needed to fix rounding issues with FE_TOWARDZERO (this seems like a gdtoa bug). The patch also adds a few tests for these issues, along with also taking the opportunity to clean up some of the previous tests to do the asserts in the right order (i.e. with the first argument as the expected result, and the second one being used as the value that it is compared against). |
||
---|---|---|
.. | ||
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.