If a file descriptor is being closed, we need to permanently disable
any Notifier and remove it from the event loop. This method removes
the notifier and disables it so that the EventLoop does not use a
invalid file descriptor.
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.
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.
The streaming operator doesn't short-circuit, consider the following
snippet:
void foo(InputStream& stream) {
int a, b;
stream >> a >> b;
}
If the first read fails, the second is called regardless. It should be
well defined what happens in this case: nothing.
DateTime::create() takes a date/time in local time, but it set
tm_isdst to 0, which meant it was in local winter time always.
Set tm_isdst to -1 so that times during summer time are treated
in summer time, and times in winter time are treated as winter
time (when appropriate). When the time is adjusted backward by
one hour, the same time can be in winter time or summer time,
so this isn't 100% reliable, but for most of the year it should
work fine.
Since LibJS uses DateTime, this means that the Date tuple
ctor (which creates a timestamp from year/month/day/hours/etc
in local time) and getTime() should now have consistent (and
correct) output, which should fix#3327.
In Serenity itself, dst handling (and timezones) are unimplemented
and this doens't have any effect yet, but in Lagom this has an effect.
Before, we had about these occurrence counts:
COPY: 13 without, 33 with
MOVE: 12 without, 28 with
Clearly, 'with' was the preferred way. However, this introduced double-semicolons
all over the place, and caused some warnings to trigger.
This patch *forces* the usage of a semi-colon when calling the macro,
by removing the semi-colon within the macro. (And thus also gets rid
of the double-semicolon.)
It wasn't used anywhere.
Also, if it were used, then it should have been marked AK_NONCOPYABLE().
Or even more cleanly, it should use a RefPtr<> or OwnPtr<> instead of
a 'naked' pointer. And because I didn't want to impose any such decision
on a possible future use case that we don't even know, I just removed
that unused feature.
The implementation in LibC did a timestamp->day-of-week conversion
which looks like a valuable thing to have. But we only need it in
time_to_tm, where we already computed year/month/day -- so let's
consolidate on the day_of_week function in DateTime (which is
getting extracted to AK).
The JS tests pointed out that the implementation in DateTime
had an off-by-one in the month when doing the leap year check,
so this change fixes that bug.
Set member variables after calling mktime(), which canonicalizes
out-of-range values.
With this, DateTime::create(2020, 13, ...) will return a DateTime
on Jan 2021 (assuming the other parameters are in range).
A malicious caller can create a SocketAddress for a local unix socket with an
over-long name that does not fit into struct sock_addr_un.
- Socket::connet: This caused the 'sun_path' field to
overflow, probably overwriting the return pointer of the call frame, and thus
crashing the process (in the best case).
- SocketAddress::to_sockaddr_un: This triggered a RELEASE_ASSERT, and thus
crashing the process.
Both have been fixed to return a nice error code instead of crashing.
Code is pretty trivial. If someone needs "float" support, a copy-paste
will be in place.
Build system was confused between math.h from rootfs, and toolchain. I
fixed the problem caused by `math.h` by locally using the builtin
`isnan()` from the compiler. It's ugly - but works. I am looking for
other alternatives.
I noticed on boot, WindowServer was getting an veil error:
[WindowServer(13:13)]: Rejecting path '/res/themes/Default.ini' since it hasn't been unveiled with 'c' permission.
[WindowServer(13:13)]: 0xc014367f _ZN6Kernel3VFS34validate_path_against_process_veilEN2AK10StringViewEi +681
[WindowServer(13:13)]: 0xc01439d7 _ZN6Kernel3VFS12resolve_pathEN2AK10StringViewERNS_7CustodyEPNS1_6RefPtrIS3_EEii +163
[WindowServer(13:13)]: 0xc0143d03 _ZN6Kernel3VFS4openEN2AK10StringViewEitRNS_7CustodyENS1_8OptionalINS_9UidAndGidEEE +121
[WindowServer(13:13)]: 0xc016fbc4 _ZN6Kernel7Process8sys$openEPKNS_7Syscall14SC_open_paramsE +854
[WindowServer(13:13)]: 0xc0164af8 syscall_handler +1320
[WindowServer(13:13)]: 0xc0164541 syscall_asm_entry +49
[WindowServer(13:13)]: 0x08097ca0 open_with_path_length +24
[WindowServer(13:13)]: 0x08097cf8 open +63
[WindowServer(13:13)]: 0x080a3c59 fopen +31
[WindowServer(13:13)]: 0x0806abf0 _ZN4Core10ConfigFile4syncEv +48
[WindowServer(13:13)]: 0x0806af6a _ZN4Core10ConfigFileD2Ev +16
[WindowServer(13:13)]: 0x08093e2a _ZN3Gfx17load_system_themeERKN2AK6StringE +1869
[WindowServer(13:13)]: 0x08048633 main +491
[WindowServer(13:13)]: 0x08048dae _start +94
With some digging I found out that the ConfigFile class was causing
trying to flush writes of default values, not present in the .ini
file back to disk on destruction of the object.
This sneaky behavior from ConfigFile seems to violate the public facing
semantics of the function (it's const). It also makes it very hard to reason
about the system with technologies like unveil where we are trying to
explicitly state what is exposed to apps, how those exposed items can be
used.
The functionality also doesn't seem to be all that useful, as we'll just
return the default value from the API's anyway.
This change removes the write back of default values.
Now that we don't keep a C compiler around in the toolchain (to save
space) we can't have .c files in the build.
This reminds me that #362 exists and we should fix that at some point.
