It's awkward to handle them differently. But this change means we
need to expose them to the generated code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us marshal and unmarshal undefined complex types; the fromwire
function will allocate it for us, so we don't even need to know the size.
This turns out to be really nice for marshalling 'struct crypto_state'.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For our internal CSV files, we can specify the type explicitly rather
than trying to guess (eg. bool).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Pretty! Takes an int instead of the enum directly, because in the
main daemon we call it via a function pointer, so want them all the
same type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It implies tal_count() gives the length. Great for almost all callers which
don't care if there are extra bytes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This removes some redundancy in creating messages, but also allows
a lazy form or parsing without explicitly checking the type.
A helper fromwire_peektype() is added to look up the type and handle
the too-short-for-type problem.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We emit them into the generated code at appropriate points, but it
would be better if we simply preserved the order they were given in.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a bit more awkward for large structures, but avoids
indirection for the simpler ones (I copied the structures for the test
code, however). We also remove explicit padding.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changed the generation of messages so that we pass in a reference to the
secp256k1_context if it is required by the underlying primitive
function. This gets rid of the global `secp256k1_ctx` variable and
adheres closer to how we've been handing in the context so far.
Rusty Russell
Christian Decker