LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-10 13:00:29 +03:00
Code Issues Packages Projects Releases Wiki Activity
ad5d217e76
ladybird/Kernel/KLexicalPath.h

23 lines
501 B
C
Raw Normal View History

Kernel: Add KLexicalPath This adds KLexicalPath, which are a few static functions which aim to mostly emulate AK::LexicalPath. They are however constrained to work with absolute paths only, containing no '.' or '..' path segments and no consecutive slashes. This way, it is possible to avoid use StringView for the return values and thus avoid allocating new String objects. As explained above, the functions are currently very strict about the allowed input paths. This seems to not be a problem currently. Since the functions VERIFY this, potential bugs caused by this will become immediately obvious.
2021-07-06 12:16:17 +03:00
/*
* Copyright (c) 2021, Max Wipfli <max.wipfli@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/StringView.h>
Kernel: Add KLexicalPath::try_join and use it This adds KLexicalPath::try_join(). As this cannot be done without allocation, it uses KString and can fail. This patch also uses it at one place. All the other cases of String::formatted("{}/{}", ...) currently rely on the return value being a String, which means they cannot easily be converted to use the new API.
2021-07-06 13:05:50 +03:00
#include <Kernel/KString.h>
Kernel: Add KLexicalPath This adds KLexicalPath, which are a few static functions which aim to mostly emulate AK::LexicalPath. They are however constrained to work with absolute paths only, containing no '.' or '..' path segments and no consecutive slashes. This way, it is possible to avoid use StringView for the return values and thus avoid allocating new String objects. As explained above, the functions are currently very strict about the allowed input paths. This seems to not be a problem currently. Since the functions VERIFY this, potential bugs caused by this will become immediately obvious.
2021-07-06 12:16:17 +03:00
namespace Kernel::KLexicalPath {
bool is_absolute(StringView const&);
bool is_canonical(StringView const&);
StringView basename(StringView const&);
StringView dirname(StringView const&);
Vector<StringView> parts(StringView const&);
Kernel: Replace KResult and KResultOr<T> with Error and ErrorOr<T> We now use AK::Error and AK::ErrorOr<T> in both kernel and userspace! This was a slightly tedious refactoring that took a long time, so it's not unlikely that some bugs crept in. Nevertheless, it does pass basic functionality testing, and it's just real nice to finally see the same pattern in all contexts. :^)
2021-11-08 02:51:39 +03:00
ErrorOr<NonnullOwnPtr<KString>> try_join(StringView const&, StringView const&);
Kernel: Add KLexicalPath::try_join and use it This adds KLexicalPath::try_join(). As this cannot be done without allocation, it uses KString and can fail. This patch also uses it at one place. All the other cases of String::formatted("{}/{}", ...) currently rely on the return value being a String, which means they cannot easily be converted to use the new API.
2021-07-06 13:05:50 +03:00
Kernel: Add KLexicalPath This adds KLexicalPath, which are a few static functions which aim to mostly emulate AK::LexicalPath. They are however constrained to work with absolute paths only, containing no '.' or '..' path segments and no consecutive slashes. This way, it is possible to avoid use StringView for the return values and thus avoid allocating new String objects. As explained above, the functions are currently very strict about the allowed input paths. This seems to not be a problem currently. Since the functions VERIFY this, potential bugs caused by this will become immediately obvious.
2021-07-06 12:16:17 +03:00
}
Reference in New Issue Copy Permalink