This abstracts a vector of Cell* with a strongly typed span() accessor
that gives you Span<T*> instead of Span<Cell*>.
It is intended to replace MarkedValueList in situations where you only
need to store pointers to Cell (or an even more specific type of Cell).
The API can definitely be improved, it's just the bare basics for now.
The Serenity Stream API is the name for the new set of classes intended
to replace IODevice and its descendants. It provides more flexibility
for subclasses by allowing each subclass to override all the possible
functionalities according to their wishes.
Stream is the base class which implements majority of the functionality
expected from a readable and writable stream. SeekableStream adds
seeking on top, and provides a couple utility methods which derive from
seek. Socket adds a couple of BSD socket utility functions such as
checking whether there is data available to read and checking the
pending bytes on the socket.
As for the concrete classes, there is File which is a SeekableStream and
is intended to operate on file-like objects; and TCPSocket, UDPSocket
and LocalSocket, which handle TCP, UDP and UNIX sockets respectively.
The concrete classes do not do buffering by default. For buffering
functionality, a set of augmentative classes named BufferedSeekable and
BufferedSocket have been implemented, intended to wrap a SeekableStream
and a Socket, respectively.
This fixes at least half of our LibC includes in the kernel. The source
of truth for errno codes and their description strings now lives in
Kernel/API/POSIX/errno.h as an enumeration, which LibC includes.
This syscall is very much similar to open(2), with the difference of
accepting a string and a length, instead of requiring a null-terminated
string. This way, if the string passed is not null-terminated, we can
still perform the syscall.
Otherwise we'd end up putting the prompt *after* the previous prompt
instead of *over* it when showing suggestions that span more lines than
are available without scrolling.
This makes them harder to miss for spammy apps when UBSAN is not deadly.
Don't commit to making the warnln red at the momment, because that would
probably be a nuisance if stderr is not a tty.
This is the same strategy that LLVM's compiler-rt uses to make sure that
each UBSAN error is only reported once, when UBSAN is *not* deadly.
Otherwise, each time we head through a UB codepath, we will log the same
error over and over. That behavior just adds noise to the logs and makes
it nearly impossible to run binaires that have some common code path
with flagged UB in them.
compiler-rt goes the extra step to make sure the "clear" action is
atomic, but we don't really have that many multi-threaded apps gettting
tested with UBSAN yet, so we can add that later.
