* Pass the correct source address for copying tine addr_length.
Previously, this was broken when addr_length was non-nullptr.
* Copy min(sizeof(address), address_length) bytes into address,
instead of sizeof(address), which might be larger than the
user buffer.
* Use sockaddr_storage instead of sockaddr_un. In practice they're
both the same size, but this is what sockaddr_storage is for.
With this (in particular, the first fix), `ue /bin/ntpquery`
actually gets past the recvfrom() call :^)
With this, `ue /bin/ntpquery` can be used to test sendto() and
recvfrom() in ue. (It eventually hits an unimplemented FILD_RM64,
but not before doing emulated network i/o and printing response
details.)
Instead of everyone overriding save_to() and set_property() and doing
a pretty asymmetric job of implementing the various properties, let's
add a bit of structure here.
Object properties are now represented by a Core::Property. Properties
are registered with a getter and setter (optional) in constructors.
I've added some convenience macros for creating and registering
properties, but this does still feel a bit bulky. We'll have to
iterate on this and see where it goes.
Previously, the strucutre of the HackStudio widgets made it so the
actions tab would be hidden when the "edit mode" was something other
than EditMode::Text (for example, when using the form editor).
This commit adds an equivalent to the sh 'case' construct, except it's
much more pleasing to look at and write:
```sh
match "$something" {
p1 { echo "p1!" }
p2 { echo "p2!" }
* { echo "string catch-all!" }
}
```
is the equivalent of:
```sh
case $something in
p1)
echo "p1!"
;;
p2)
echo "p2!"
;;
*)
echo "catch-all!"
;;
esac
```
Since our shell does not treat lists as strings, matching lists is also
possible:
```sh
match (1foo 2foo foo3) {
(?foo 2* *) { echo wowzers! }
(* * *) { echo 3-element list catch-all }
}
```
OutputMemoryStream was originally a proxy for DuplexMemoryStream that
did not expose any reading API.
Now I need to add another class that is like OutputMemoryStream but only
for static buffers. My first idea was to make OutputMemoryStream do that
too, but I think it's much better to have a distinct class for that.
I originally wanted to call that class FixedOutputMemoryStream but that
name is really cumbersome and it's a bit unintuitive because
InputMemoryStream is already reading from a fixed buffer.
So let's just use DuplexMemoryStream instead of OutputMemoryStream for
any dynamic stuff and create a new OutputMemoryStream for static
buffers.
xterms send a bitmask (+ 1) in the 2nd CSI parameter if "special"
keys (arrow keys, pgup/down, etc) are sent with modifiers held down.
Serenity's Terminal used to send ^[[O, which is a nonexistent
escape sequence and a misread of VT100's ^[O (ie the '[' is
replaced by 'O'). Since the xterm scheme also supports shift
and alt modifiers, switch to that.
More flexible, and makes ctrl-left/right and alt-left/right work
in SerenityOS's bash port.
Also do this for page up/down.
No behavior change for SerenityOS's Shell.
Fix gracefully failing these calls if used within IRQ handlers. If we're
handling IRQs, we need to handle these failures first, because we can't
really resolve page faults in a meaningful way. But if we know that it
was one of these functions that failed, then we can gracefully handle
the situation.
This solves a crash where the Scheduler attempts to produce backtraces
in the timer irq, some of which cause faults.
Fixes#3492
Consider the following snippet:
void foo(InputStream& stream) {
if(!stream.eof()) {
u8 byte;
stream >> byte;
}
}
There is a very subtle bug in this snippet, for some input streams eof()
might return false even if no more data can be read. In this case an
error flag would be set on the stream.
Until now I've always ensured that this is not the case, but this made
the implementation of eof() unnecessarily complicated.
InputFileStream::eof had to keep a ByteBuffer around just to make this
possible. That meant a ton of unnecessary copies just to get a reliable
eof().
In most cases it isn't actually necessary to have a reliable eof()
implementation.
In most other cases a reliable eof() is avaliable anyways because in
some cases like InputMemoryStream it is very easy to implement.
