The spec 4af8e1841151f0c6e8151979d6c89d11839b2f65 uses a 32-byte 'channel-id'
field, not to be confused with the 8-byte short ID used by gossip. Rename
appropriately, and update to the new handshake protocol.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
Rusty Russell