| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Serenity/Linux/macOS ignore the file descriptor when an anonymous
mapping is requested. However, BSDs require the fd to be -1.
|
|
This can almost be identical to the Linux version, except that the
`pthread_attr_t` object is populated using a call to
`pthread_attr_get_np` instead of `pthread_getattr_np`.
FreeBSD also needs `pthread_atttr_t` to be initialized using
`pthread_attr_init` instead of zero-initialization, but it's the
technically correct thing to do on Linux as well.
|
|
On all systems I've checked, pthread functions return the positive error
code directly.
|
|
|
|
|
|
Otherwise the bit twiddling goes all wrong and breaks some boundary
cases.
Fixes `StringView::contains(31-chars)`.
|
|
|
|
This constructor relied on running strlen implicitly on its argument,
thereby potentially causing out-of-bound reads (some of which were
caught a few days ago). The removal of this constructor ensures that the
caller must explicitly pass the size of the string by either:
1) Using operator""sv on literal strings; or
2) Calling strlen explicitly, making it clear that the size of the view
is being calculated at runtime.
|
|
The StringView(char const*) constructor is being removed, and there was
only a few users of this left, which are also cleaned up in this commit.
|
|
During the removal of StringView(char const*), all users of these
functions were removed, and they are of dubious value (relying on
implicit StringView conversion).
|
|
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
|
|
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
|
|
Error::from_string_literal now takes direct char const*s, while
Error::from_string_view does what Error::from_string_literal used to do:
taking StringViews. This change will remove the need to insert `sv`
after error strings when returning string literal errors once
StringView(char const*) is removed.
No functional changes.
|
|
This commit moves the length calculations out to be directly on the
StringView users. This is an important step towards the goal of removing
StringView(char const*), as it moves the responsibility of calculating
the size of the string to the user of the StringView (which will prevent
naive uses causing OOB access).
|
|
Since all uses of SourceGenerator are with literal strings, there is no
need to burden generators with the sv suffix.
|
|
This moves out the calculation of the char* out to the formatter.
Additionally, we now print (null) when a null pointer is passed.
|
|
This makes the assumption that we never pass a stack-allocated char
array to CheckedFormatString arguments (dbgln, outln, warnln). This
assumption seems to hold true for the current state of Serenity code, at
least. :^)
|
|
Previously we would treat the empty string as `null`. This caused
JavaScript like this to fail:
```js
var object = {};
try {
object = JSON.parse("");
} catch {}
var array = object.array || [];
```
Since `JSON.parse("")` returned null instead of throwing, it would set
`object` to null and then try and use it instead of using the default
backup value.
|
|
Is it another great upgrade to our PNG encoder like in 9aafaec259?
Well, not really - it's not a 2x or 55x improvement like you saw there,
but still it saves something:
- a screenshot of a blank Serenity desktop dropped from about 45 KiB
to 40 KiB.
- re-encoding NASA photo of the Earth to PNG again saves about 25%
(16.5 MiB -> 12.3 MiB), compared to not using filters.
[1]: https://commons.wikimedia.org/wiki/File:The_Blue_Marble_(remastered).jpg
|
|
Even shifting 0 by more than the value size is UB.
|
|
|
|
|
|
|
|
|
|
This commit has no behavior changes.
In particular, this does not fix any of the wrong uses of the previous
default parameter (which used to be 'false', meaning "only replace the
first occurence in the string"). It simply replaces the default uses by
String::replace(..., ReplaceMode::FirstOnly), leaving them incorrect.
|
|
Matching the similar align_up_to helper
|
|
These are functions that can be expressed with just normal operators,
but would be very repetetive.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Leon Albrecht <leon2002.la@gmail.com>
|
|
ByteBuffer::get_bytes_for_writing() was only ensuring capacity before
this patch. The method needs to call resize to register the appended
data, otherwise it will be overwritten with next data addition.
|
|
This used to be `__CLION_IDE_` before, but it seems to have been fixed
in the latest EAP.
|
|
|
|
|
|
Usually the values of the previous and next pointers of deleted buckets
are never used, as they're not part of the main ordered bucket chain,
but if an in-place rehashing is done, which results in the bucket being
turned into a free bucket, the stale pointers will remain, at which
point any item that is inserted into said free-bucket will have either
a stale previous pointer if the HashTable was empty on insertion, or a
stale next pointer, resulting in undefined behaviour.
This commit also includes a new HashMap test that reproduces this issue
|
|
This reverts commit 50c88e5e3a6918f99cfcfb802d111cb22a87645c.
The intention was to add them to NonnullRefPtr, not NonnullOwnPtr. That
is also what was advertised in the PR, but not actually done in the
reverted commit.
|
|
|
|
Only the kernel actually uses RefPtrTraits, so let's not burden
userspace builds with the complexity.
|
|
Only the kernel expects AK::Weakable to lock its refcount manipulation,
so let's not force userspace to pay for that as well.
|
|
|
|
|
|
|
