--- Log opened Tue Dec 25 00:00:02 2018
14:57 < andytoshi> what do people think about https://github.com/ElementsProject/secp256k1-zkp/pull/37 ? does it make sense to export struct sizes as constants?
14:58 < andytoshi> or is this person just confused? i don't understand in what context somebody wouldn't have access to the headers
16:30 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
16:31 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #secp256k1
16:47 < gmaxwell> I think thats a little confused...
16:48 < gmaxwell> I mean, in general we should very very strongly prefer to make things opaque, in which case we need either allocators or sizes.
16:49 < gmaxwell> but if it's not opaque, it's not opaque. and we can't just easily export a size except via a macro which sizeofs or similar, since the size depends on the abi.
16:49 < gmaxwell> (and a function that returns the size by sizeof internally couldn't be used to allocate on the stack... which is basically the only argument I'm aware of for not having the type be entirely opaque)
16:50 < sipa> agree
16:50 < sipa> one possibility is having a serialized format with constant guaranteed size
16:54 < gmaxwell> also, if it's 'opaque', we could still have a macro to get the size that might allow some kind of stack usage.
16:56 < sipa> ah, sorry i missed some context, this os for stack allocation
16:57 < gmaxwell> no, well thats what I'm talking about I think the PR doesn't want stack allocation.
16:57 < gmaxwell> but if stack allocation wasn't an objective the answer is that it should be opaque with a allocation (or size) function....
16:57 < gmaxwell> not non-opaque with a function that returns the size.
--- Log closed Wed Dec 26 00:00:05 2018