That's just silly :)
Also fix that one use of read_line() which assumes it will
null-terminated in mount.cpp (this would've blown up if the IODevice was
at EOF and had a line with the same size as max_size).
Problem:
- The default constructor is is deleted because NonnullRefPtr has no
default constructor and there is a member variable of that type, but
the function is set as `= default`.
Solution:
- Remove the code because the function is actually deleted implicitly.
This makes most operations thread safe, especially so that they
can safely be used in the Kernel. This includes obtaining a strong
reference from a weak reference, which now requires an explicit
call to WeakPtr::strong_ref(). Another major change is that
Weakable::make_weak_ref() may require the explicit target type.
Previously we used reinterpret_cast in WeakPtr, assuming that it
can be properly converted. But WeakPtr does not necessarily have
the knowledge to be able to do this. Instead, we now ask the class
itself to deliver a WeakPtr to the type that we want.
Also, WeakLink is no longer specific to a target type. The reason
for this is that we want to be able to safely convert e.g. WeakPtr<T>
to WeakPtr<U>, and before this we just reinterpret_cast the internal
WeakLink<T> to WeakLink<U>, which is a bold assumption that it would
actually produce the correct code. Instead, WeakLink now operates
on just a raw pointer and we only make those constructors/operators
available if we can verify that it can be safely cast.
In order to guarantee thread safety, we now use the least significant
bit in the pointer for locking purposes. This also means that only
properly aligned pointers can be used.
...instead of maybe bitmap + a single mime type and its corresponding data.
This allows drag&drop operations to hold multiple different kinds of
data, and the views/applications to choose between those.
For instance, Spreadsheet can keep the structure of the dragged cells,
and still provide text-only data to be passed to different unrelated editors.
From https://youtu.be/YNSAZIW3EM0?t=1474:
"Hmm... I don't think that name is right! From the perspective of
userspace, this is a file descriptor. File description is what the
kernel internally keeps track of, but as far as userspace is concerned,
he just has a file descriptor. [...] Maybe that name should be changed."
Core::File even has a member of this enum type... called
m_should_close_file_descriptor - so let's just rename it :^)
This reverts my previous commit in WebServer and fixes the whole issue
in a much better way. Instead of having the MIME type guesser take a
URL (which we don't actually have in the WebServer at that point),
just take a path as a StringView.
Also, make use of the case-insensitive StringView::ends_with() :^)
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).
