< jonasschnelli> what is the best strategy to deserialize a varlen string from a stream with unknown length (burst read)
< jonasschnelli> NetMessage reads in bytes with unknown length, so it is unknown if the varstring is complete in buffer
< jonasschnelli> I'd like to figure out if the all bytes for the varlen-string are copied to the buffer
< fanquake> wumpus 13796 and 13852 (both 0.16) should be able to go in.
< wumpus> jonasschnelli: I'm confused--the normal varstring is unknown length isn't it?
< wumpus> fanquake: thanks will take a look
< jonasschnelli> wumpus: the problem is more complicated. I'm reading in bytes from a socket and I'd like to deserialize a varstring,... but need to know how many bytes I need to read from the socket
< jonasschnelli> So I need to look at the varint part of the varstring to know when I have finished readin the buffer that contains the whole varstring
< jonasschnelli> Since it can be 1 byte to n bytes
< jonasschnelli> not n but a verstring of 64bit length
< wumpus> the only way to do that would be to have a fixed-sized header that specifies the length to read, although this is typically DoS-prone especially if the buffer is allocated at once and remote can specify a very large buffer
< jonasschnelli> wumpus: Yes. But nevermind. I think i'm creating a non-existing problem
< jonasschnelli> I'm implementing BIP151 message structures: https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#encrypted-messages-structure
< jonasschnelli> And the varstring command made me some problems... But I forgot that the inner message structure is always present at complete length (since it's MAC has must been checked beforehand)
< gmaxwell> lordcow in #bitcoin reports a compile failure on freebsd: https://pastebin.com/wBN0YChc
< gmaxwell> 08:02:23 < LordCow> gmaxwell: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
< wumpus> hmm let me try
< wumpus> I did a recompile on freebsd yesterday so I'd be surprised
< wumpus> of master, though
< wumpus> anyhow probably best for them to create an issue w/ all the version information
< wumpus> it is possible that #13442 fixes it because it converts the failing inline assembly to intrinsice
< gribble> https://github.com/bitcoin/bitcoin/issues/13442 | Convert the 1-way SSE4 SHA256 code from asm to intrinsics by sipa · Pull Request #13442 · bitcoin/bitcoin · GitHub
< jimpo> Would love more reviews on #12254
< gribble> https://github.com/bitcoin/bitcoin/issues/12254 | BIP 158: Compact Block Filters for Light Clients by jimpo · Pull Request #12254 · bitcoin/bitcoin · GitHub
< jonasschnelli> jimpo: Will do... almost forgot about it. But I guess its something for 0.18 which means its not pressing
< jimpo> thx
< jimpo> Not sure about the release schedule, but it's blocking further progress on block filter indexing and ultimately BIP 157 P2P support
< jonasschnelli> jimpo: Yes. Review can always happen,.. a merge though requires spun off of the 0.17 branch (since we are in feature-freeze currently)
< jonasschnelli> But we all want to see progress on BIP157...
< gmaxwell> MarcoFalke: sipa: is anyone running 13907 on a listening node? I need feedback on if I'm going to have to increase the limit to 100 or not.
< sipa> will run
< gmaxwell> (i just don't want to bother updating it to pull the tests without knowing what threshold we're going to use)
< sipa> running
< gmaxwell> sipa: thanks
< gmaxwell> sipa: grep log for "locator" after a bit