Thanks for explanation!

Thank you very much! I will definately look into it. This might be usefull in some other circumstances.

The easiest approach to making a value like this is to write C (or asm) code on your machine, compile it, and copy the hexdump of the function. You need to save it under the same name the function is supposed to be, and make sure you compile (or write, in case of asm code) it as Position Independent Code.
You can store it in as big as a variable you want to, but you need to get the endianness correct (Array element are stored in sequence, but a long long is stored as chars in reverse!)

The code you write gets assembled separetely from the test, so the test only knows the type of something from the type declaration.
You can write an array / single value in one file, then make a function declaration in another file. This makes the second file treat your value as a function.
The array I created is a byte code that multiplies the values (that are in two specific registers) and return the result. It doesn't matter that it is an ll array, the second file treats it as a function, so it calls it and it just works.

da fuq?

This assumes that the *dst buffer will be bigger than it actually needed to be (because you add on those extra spaces before truncating them).

So it relies that the caller gave you that extra memory to play with.

So maybe you will be lucky... or maybe you wont be...

I can agree with you, however, the length of an interval in a mathematical sense does not depend on inclusiveness if we are talking about intervals over the real numbers, which is a fair assumption unless stated otherwise.

a safer planet