[PATCH] D126254: Add support for decoding base64.
serge via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon May 23 22:38:09 PDT 2022
serge-sans-paille added inline comments.
================
Comment at: llvm/include/llvm/Support/Base64.h:58
+llvm::Error decodeBase64(llvm::StringRef Bytes, OutputBytes &Output) {
+ constexpr char DecodeTable[] = {
+ 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64,
----------------
if declared static, this will go in RO data and lead to more efficient code, see https://godbolt.org/z/z4zsqKqEn
================
Comment at: llvm/include/llvm/Support/Base64.h:66
+ 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51};
+ auto decodeBase64Byte = [](uint8_t Ch) -> char {
+ if (Ch >= sizeof(DecodeTable))
----------------
Shouldn't `DecodeTable` be part of the capture list?
================
Comment at: llvm/include/llvm/Support/Base64.h:77
+ return createStringError(std::errc::illegal_byte_sequence,
+ "Base64 encoded strings must be a multiuple of 4 "
+ "bytes in length");
----------------
nit: multiple
================
Comment at: llvm/include/llvm/Support/Base64.h:85
+ const char Byte = Bytes[Idx + ByteIdx];
+ if (Byte == '=') {
+ if (ByteIdx <= 1) {
----------------
I wonder if the code would be simpler to read if the handling of the trailing '=' would be in a separate loop, that way we would have a first loop that does the fast and straight-forward processing of the stream, then a slightly more complex code to handle the trailing bytes?
================
Comment at: llvm/include/llvm/Support/Base64.h:100
+ }
+ if (Hex64Bytes[ByteIdx] == 64)
+ return createStringError(
----------------
this `if` could be nested in above `else`
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126254/new/
https://reviews.llvm.org/D126254
More information about the llvm-commits
mailing list