The first argument for LexicalPath::join was a String const&, which
resulted in an unnecessary memory copy when invoked with a StringView.
Changing the type of the parameter to StringView avoids the extra cost.
This was noticed while working on #10230.
We already know the length of these substrings, so there's no need to
check their lengths using strlen in the StringView(char*) constructor.
This patch also removes an accidental 1-byte OOB read that was left over
from when this method received null-terminated char pointers instead of
string views, as well removes the unnecessary lambda call (two of the
checks were impossible, and this was only called in one place, so we can
just inline it)
This was required before commit 5f724b6ca1
when we were building LibC before libstdc++ headers were available in
the sysroot. However as noted in that commit, we never actually needed
to be building LibC before libstdc++, so we can go ahead and remove this
ancient hack.
The only use of this define was removed in commit
5f724b6ca1, over a year ago.
The define was there to prevent the LibC build we built before libstdc++
from complaining about missing libgcc symbols. However, as noted in that
commit, we never actually needed to build LibC at all.
"result" is a tad bit too generic to provide a clash-free experience -
we found instances in LibJS where this breaks already. Essentially this
doesn't work:
auto foo = TRY(bar(result));
Because it expands to the following within the TRY() scope:
{
auto result = bar(result);
...
}
And that of course fails:
error: use of ‘result’ before deduction of ‘auto’
The simple solution here is to use a name that is much less likely to
clash with anything used in the expression ("_temporary_result"). :^)
DisjointChunks<T> provides a nice interface over multiple sequential
Vector<T>'s, allowing the user to iterate over/index into/slice from
said buffers as if they were a single contiguous buffer.
To work with views on such objects, DisjointSpans<T> is provided, which
has the same behaviour but does not own the underlying objects.
These are required in the specification and used by the web's URL
built-in, this commit also removes the Badge<AK::URL> from URLParser
to allow other classes that need to call the parser directly like the
web's URL built-in to do so.
This should:
- Accept const& on both sides
- Not involve implicit conversions on either side
otherwise the argument order would be deemed significant, and trip this
warning.
Serenity has explicit_bzero() in LibC with the same implementation,
however we need to be able to use this from Lagom on all platforms
that we support building serenity on. I've implemented it in AK for
this reason.
This removes the awkward String::replace API which was the only String
API which mutated the String and replaces it with a new immutable
version that returns a new String with the replacements applied. This
also fixes a couple of UAFs that were caused by the use of this API.
As an optimization an equivalent StringView::replace API was also added
to remove an unnecessary String allocations in the format of:
`String { view }.replace(...);`
This was needlessly copying StringView arguments, and was also using
strstr internally, which meant it was doing a bunch of unnecessary
strlen calls on it. This also moves the implementation to StringUtils
to allow API consistency between String and StringView.
This variant of dbgputstr does not lock the global log lock, as it is
called before the current or any other processor was initialized,
meaning that:
A) The $gs base was not setup yet, so we cannot enter into critical
sections, and as a result we cannot use SpinLocks
B) No other processors may try to print at the same time anyway
This bit me because I accidentally made the destructor for a class which
was wrapped in an Optional private. This causes none of the Optional
destructors to be able to be deduced, which when combined with concepts
causes an internal compile error in GCC 10.3.0+. This commit adds a note
here to make sure that future encounters of this bug does not surprise
people.
c27abaabc4 moved this out of the global
namespace, but did not qualify its users.
While this seems to be fine (sometimes, somehow), let's qualify it to
avoid random breakage.
This is in preparation for making KBufferBuilder::append() and friends
return a KResult. Long-term we should come up with a solution that works
for both kernel and userspace clients of the JSON API.