As title said. However I'm not even sure if it possible yet. Unless I missed something in the documentation.

Counting Mode, Validation Mode, and Unbounded Output mode need to all be tested under this new paradigm.

• Counting mode tests (cxnrtocxn(&output_size, (OutChar*)nullptr, &input_size, input);)
• Validation mode tests (cxnrtocxn(nullptr, (OutChar*)nullptr, &input_size, input);)
• Unbounded mode tests (cxnrtocxn(nullptr, (OutChar*)nullptr, &input_size, input);)

These can likely be added as additional assertions to the current roundtrip tests, to avoid having to make Yet Another Harness for them. It is also fine because the arrays there are sized specifically to avoid hitting any limits during single write-outs. Excessively-huge buffers will need to be made in the bulk cases, especially for unbounded output however.

https://thephd.dev/cuneicode-and-the-future-of-text-in-c

output size counting (iconv(cd, inbuf, inbytesleft, nullptr, outbytesleft));

I'm not very sure about this. libiconv has the concept of reversible and irreversible mappings. From the manual of it, it said it will only returns the number of non-reversible conversions performed during this call.

https://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.17/iconv.3.html

I have no idea if this number is the same as the output size or not.

Btw, I have never seen people on the internet use libiconv this way. Most of the time, they guess the output size. I don't even know that it's possible to have iconv to do a dry run to calculate the output size like this. I think this is libicu style!

https://stackoverflow.com/questions/13297458/simple-utf8-utf16-string-conversion-with-iconv

This will boost the popularity of your library.

When building commit 2f30d70 on Fedora linux, get the following error:

/home/cuneicode/source/ztd/cuneicode/detail/index.cpp:74:33: error: no member named 'ranges_adl' in namespace 'ztd::ranges'
auto __last = ::ztd::ranges::ranges_adl::adl_cend(__index_code_point_map);
~~~~~~~~~~~~~~~^

https://thephd.dev/the-c-c++-rust-string-text-encoding-api-landscape

In your article, you didn't mention it.

The title has it: while we thoroughly test the single-off conversions, we don't fully test the multi-conversion functionality, so that should be added to the test suite. We should also implement such tests using the registry and similar. Finally, we need to test the allocating and non-allocating functions.

• Test multi (cxnsrtocxns) bulk functions for all 5 core types, similar to the single tests
• Test single conversions for the cnc_conversion types for all 5 core types / encodings (execution, wide execution, UTF-8, UTF-16, UTF-32)
• Test multi conversions for the cnc_conversion types for all 5 core types / encodings (execution, wide execution, UTF-8, UTF-16, UTF-32)
• Test allocation successes and failures for cnc_registry and related opening functions
• Test that the heap is not used when the space-providing functions are used for the registry and similar.

Please tell me how to do manual deployment to get started. I have no problems building people's software with CMake, but I personally don't use CMake as the build system for my code. I'm a hobbyist and I prefer using an IDE that I could click and have it build and run my program instead of having to write a build script. I don't want to use CMake, including CMake GUI.