We can once again create 2mb statically-linked Python binaries:
$ make -j8 m=tiny o/tiny/examples/pyapp/pyapp.com
$ ls -hal o/tiny/examples/pyapp/pyapp.com
-rwxr-xr-x 1 jart jart 2.1M May 1 14:04 o/tiny/examples/pyapp/pyapp.com
$ o/tiny/examples/pyapp/pyapp.com
cosmopolitan is cool!
The regression was caused by Python thread support in b15f9eb58
- Introduce -v and --verbose flags
- Don't print stats / diagnostics unless -v is passed
- Reduce --top_p default from 0.95 to 0.70
- Change --reverse-prompt to no longer imply --interactive
- Permit --reverse-prompt specifying custom EOS if non-interactive
The new stack size is 256kb in order to compromise with llama.cpp's
aggressive use of stack memory, which can't be easily patched. This
change disables the dynamic alloca() and VLA warnings for now, plus
frame sizes for individual functions may be <=50% of the stack size
This only applies to code in the cosmo monorepo. Open source builds
should already be using an 8mb stack by default, like everyone else
When redbean is functioning as a Lua interpreter, the `-e` flag should
behave the same way as other open source language interpreters. Namely
it should exit after evaluating the code rather than showing the REPL.
Right now, cosmopolitan uses Linux Landlock ABI version 2 on Linux,
meaning that the polyfill for unveil() cannot restrict operations such
as truncate() (a limitation of Landlock's ABI from then). This means
that to restrict truncation operations Cosmopolitan instead has to ban
the syscall through a SECCOMP BPF filter, meaning that completely
legitimate truncate() calls are blocked
However, the newest version of the Landlock ABI (version 3) introduced
in Linux 6.2, released in February 2023, implements support for controlling truncation
operations. As such, the previous SECCOMP BPF truncate() filtering is
no longer needed when the new ABI is available
This patch implements unveil truncate support for Linux Landlock ABI
version 3
The rpath pledge as currently implemented in cosmopolitan does not
allow for usage of the old getdents syscall (0x4e), which is different
from the newer getdents syscall (0xd9) solely in that it does not
support 64-bit filesystems.
This means that, for example, old statically linked binaries cannot
use `readdir` and other such functions which use this syscall instead
of the more modern one, even though there is no threat in allowing
that syscall alongside the more modern one (except that the binary may
have issues with 64-bit filesystems, but that's a separate problem).
This patch fixes this.
The C standard states that, in the context of an x conversion
specifier given to scanf:
> Matches an optionally signed hexadecimal integer, whose format is
> the same as expected for the subject sequence of the strtoul
> function with the value 16 for the base argument.
- C standard, 7.23.6.2.11. The fscanf function
Cosmopolitan fails to do this, as 0 should be parsed as a 0 by such an
invocation of strtoul. Instead, cosmopolitan errors out as though such
input is invalid, which is wrong.
This means that a program such as this:
#include <stdio.h>
#undef NDEBUG
#include <assert.h>
int main()
{
int v = 0;
assert(sscanf("0", "%x", &v) == 1);
}
will not run correctly on cosmpolitan, instead failing the assertion.
This patch fixes this, along with the associated GitHub issue,
https://github.com/jart/cosmopolitan/issues/778
