Now the point I was going to make is simply to update the CLN documentation. As for the debatable optimization I made in the posted patches, I totally agree to use cl_value_len there.
weird (hypothetical?) system with alignment = 8 and sizeof(long) = "32 bits" will break the documented behaviour :-/
well, that would mean cl_value_len = 29 insted of the normal cl_value_len = 30 for 32 bit architectures and cl_value_len = 32 for 64 bit architectures, if my interpretation of CLN's header didn't fail (but such failure is quite likely anyway...): 4-byte alignment eats 2 bits, 8-byte alignment eats 3 bits off cl_value_len, at least for 32 bit architectures. And, the headers get the architecture idea from something like sizeof(long) in intparam.h: e.g. #define long_bitsize 32 (made by autoconf, I guess).
Pointer size and alignment==8, but sizeof(long)==4, hmmm, dunno what would
I don't know if (Pointer size) != sizeof(long) will work for CLN's headers. I was thinking of Pointer size = 4 and alignment = 8. Maybe I'm a fool and anybody will prove that there were never such systems and never will be...
have to be changed... What do you say is gonna break there? (BTW, the
The only thing that would break on these non-existing (?) system is the "quick conversion" from C++'s int to CLN's cl_I, for values of e. g. 2^28, contrary to the documentation. Therefore IMHO CLN's documetation could be updated to speak of 2^(cl_value_len-1) instead of 2^29. Anybody still reading? Markus