src/lib/util/encode/encode.h
src/lib/util/encode/encode.cc
Reworked into new BaseNEncoder class and derivatives
src/lib/util/tests/Makefile.am
Removed obsolete test files
added new file encode_unittest.cc
new file: src/lib/util/tests/encode_unittest.cc
deleted: src/lib/util/tests/base32hex_unittest.cc
deleted: src/lib/util/tests/base64_unittest.cc
deleted: src/lib/util/tests/hex_unittest.cc
Rewrote encoding/decoding.
src/lib/util/Makefile.am
Removed old files, added encode.cc, encode.h
src/lib/util/encode/encode.*
New implemenentation encoding and decoding not based
on boost.
optarg is not reset in musl's getopt and it leaks values to other flags.
Reset it for all systems because it cannot hurt. If you remove the
optarg reset, you should see the bug in action on alpine systems in
DstubControllerTest.commandLineArgs when parsing argv2:
```
[ RUN ] DStubControllerTest.commandLineArgs
d_controller_unittests.cc:102: Failure
Expected equality of these values:
std::string(ex.what())
Which is: "unsupported option: -b cfgName"
"unsupported option: -b"
[ FAILED ] DStubControllerTest.commandLineArgs (14 ms)
```
Prior to this change, if parseArgs() was called twice during the same
program lifetime and it stumbled on an unsupported option and throwed an
exception on the first call, the previous set of arguments lived on to
be parsed by the second call. This is a situation that likely arises
only in unit tests, but let us fix it properly to at least silence the unit
test failure on alpine, which was happening because of different
implementation of getopt from musl, and which motivated looking into how
getopt behaves. To make the bug evident even in a non-alpine environment, add an
EXPECT_THROW_MSG in DStubControllerTest.commandLineArgs when parsing argv3, and
see that it outputs "unsupported option: [s]" instead of
"extraneous command line information".
The script complains about hashes missing, but that is only temporary until they
are regenerated. A second call to check-hashes.sh will now properly check them
at the end.
- Add ability to set list element that only has keys in Translator::setItem.
- Explicitly set list elements in case they contain only keys which can
be more common now that data is a key since it is likely one can have
entries that only have code, space, and data.
- Handle no data as empty data when setting, and empty data as no data
when getting. This avoids the need to add an empty "data" element to
all options that lack it in all-options.json so that the unit tests
pass. But this goes to show that data-less entries may be encountered
in production as well, so more importantly this caters to that
scenario.
- Adjust data in kea4/all-options.json to not contain singlequotes.
There was only one occurrence of it. This is a limitation related
to unit testing only. Opened issue 3216 about it.
- Add missing tests that are not strictly related to the data key, but
they are related to option data:
- TranslatorOptionDataListTestv6.getEmpty
- TranslatorOptionDataListTestv4.get
- TranslatorOptionDataListTestv6.setEmpty
- TranslatorOptionDataListTestv4.set
- Add unit tests:
- TranslatorOptionDataListTestv4.optionsSameCodeAndSpace
- TranslatorOptionDataListTestv6.optionsSameCodeAndSpace
- Add snippet that tests setting of list element with keys only in
TranslatorTest.setItem.
Setting mandatory for keys is redundant as mentioned in RFC 7950 section
7.8.2: Any "mandatory" statements in the key leafs are ignored.
So they were removed. This now makes it consistent with how data is
declared in option-data as well.
