This is still all unvalidated work.
For all I know it might cause your computer to burst into flames,
grow an arm and a leg and an eye, and attack you with a sword.
But probably, it will just not work and I will realize that sleepy
past me was a fucking idiot (as always).
The former is finally some progress on getting NBT going,
though at this point it is all unvalidated work.
For all I know it might cause your computer to burst into flames,
grow an arm and a leg and an eye, and attack you with a sword.
But probably, it won’t do that and instead start working after I
have debugged it so much that I wish I could attack my PC with a sword.
The latter is the implementation of a change I prepared in a previous commit
when i added ErrorOrVoid.
Doesn’t compile on Void x86_32 glibc. This will need to be investigated.
I just wanted to get rid of the errors while working on other issues.
Compile command:
ccache g++ -std=c++20 -Wall -Wextra src/tools/hexnet.cpp -I./include -Lbin/lib -l:cli.so -l:libsockpp.so -o bin/tools/hexnet
Never again will you need to manually convert binary data into an array!
This tool does it for you! Get it now for only $99! Limited availability!
To process data from stdin / a pipe, just pass `-` as the file name.
I stumbled over this when writing the unit test. Previously, it would return
an error code but explicitly mark it as not being an error. This was intended
behavior but I decided to change it because I didn’t anticipate it when writing
the test.
Technically `ErrorOr<T>` can be used to pass any message alongside `T`,
but practically, it is reasonable to assume that the error code is
`ErrorCodes::SUCCESS` when `isError` is false. Therefore, this feature
should be really only used in the weirdest edge cases - if at all.
Even then, it is most likely still preferable to flag it as an error and
just hand the resulting `T` back using the long constructor
`ErrorOr<T>(bool, uint8_t, T)`.
if a unit test fails to build and old unit tests remain in place, this can
lead to confusion when the old test is run anyway.
"Why are some test cases missing?"
"Huh, it failed to build but passed?"
I tried dealing with lists in the same way as with other more basic tags
but came to the conclusion that this is most likely not feasible in the same
way that it is not feasible for compounds. It would require a mini-parser
that can deal with all sorts of tags (including nested lists and compounds).
Instead, an approach more similar to the recursion for compound tags will
be used (using its own function to deal with the missing tag headers ofc).