LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-09-19 17:27:51 +03:00
Code Issues Packages Projects Releases Wiki Activity
e253cf694e
ladybird/Kernel/KLexicalPath.h

23 lines
503 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: Make KString factories return KResultOr + use TRY() everywhere There are a number of places that don't have an error propagation path right now, so I've added FIXME's about that.
2021-09-06 20:24:54 +03:00
KResultOr<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