These are the invocations of run-time normalization validation:

https://github.com/libbitcoin/libbitcoin/blob/master/src/unicode/unicode.cpp#L114

https://github.com/libbitcoin/libbitcoin/blob/master/src/unicode/unicode.cpp#L121

This is the implementation:

https://github.com/libbitcoin/libbitcoin/blob/master/src/unicode/unicode.cpp#L101

Any attempt to use these APIs with ICU improperly linked will result in
process termination via runtime exception.

There are also unit tests that verify the same correctness at built time:

https://github.com/libbitcoin/libbitcoin/blob/master/test/unicode/unicode.cpp#L34

https://github.com/libbitcoin/libbitcoin/blob/master/test/unicode/unicode.cpp#L48

These normalization APIs (and all code that references them) are
excluded from builds that do not include the WITH_ICU preprocessor define:

https://github.com/libbitcoin/libbitcoin/blob/master/src/unicode/unicode.cpp#L87

There is no reasonable way to test for correctness at compile time. Nor
is there any reasonable way to test all possible pass-phrases, but I
think the above techniques have it sufficiently covered.
e

On 12/15/2015 10:35 AM, mlmikael wrote:
>
> Such a self-check routine would be particularly useful for the users
> that build their own ICU and Boost!
>
> I see clear reasons why a user not would want to go with your local
> ICU+Boost build process in certain cases. For those cases, as a user you
> want some kind of check on the way that doublechecks that ICU and Boost
> actually work as they should with respect to ICU.
>
> (Well - so perhaps in case LibBitcoin doesn't do it itself, just doing
> two BIP39 runs from the user code with example passwords that should
> give the same output, and check that they indeed give the correct
> output, would suffice.)
>
>
>
> On 2015-12-16 02:29, mlmikael wrote:
>> Ah, so, LibBitcoin uses ICU *through* Boost. So then, ICU must be
>> installed, and the ICU version must be satisfactorily new, and, Boost
>> must be compiled to use that ICU version and none other.
>>
>> I understand that it took an eternity to finally get to the conclusion
>> that the most straightforward thing is to build your own local ICU and
>> Boost and link them in statically. It's almost comical how foolproof
>> that way of doing it is (at least in that particular respect).
>>
>>
>> Now, I know that the BIP 39 code will throw an exception if it's
>> invoked and LibBitcoin was compiled without ICU.
>>
>> But, what if LibBitcoin was compiled "with ICU" but some aspect of it
>> was broken (e.g. Boost didn't actually link to ICU, or ICU was too
>> old, or something else) -
>>
>> Is there any code within the build process, or at LibBitcoin load
>> time, that checks that it's actually healthy -
>>
>> Or can I do anything like "assert
>> bip39_check_that_the_icu_support_is_healthy();"?
>>
>>
>> I mean, just so that the whole thing is foolproofed. Just to be sure
>> that nothing in that whole chain of things that could be broken, is
>> broken.
>>
>> Maybe then that health check should do a whole BIP39 run for 2-3
>> example input strings with content that should normalize to one and
>> the same string, and then checking that all of them give the same
>> output. If that's all that all of libbitcoin* uses ICU for.
>