1 2015-07-24 07:17:23 <venzen> hi all, what is the correct format specifier when trying to printf() a int64_t ?
 2 2015-07-24 07:18:41 <venzen> the compiler gives a general compilation error when I specify %d
 3 2015-07-24 07:43:26 <wumpus> size specifiers are based on which C type - so that depends on what int64_t is defined as. Also, it differs per platform. On POSIX, 'll' is the size specifier for long long
 4 2015-07-24 07:45:21 <wumpus> but that won't work on windows. There are a few macros you can use instead, but those are not always defined either. It is tricky to get it right for every platform. After a lot of inadvertent errors, for bitcoin core we eventually switched to a custom printf implementation (tinyformat).
 5 2015-07-24 07:46:33 <wumpus> which uses c++ features to avoid having to specify sizes at all, so it leaves any potential bugs in that regard dead in the water
 6 2015-07-24 08:03:48 <venzen> thanks wumpus, in my case I'm trying to LogPrintf() nTxFee from jtimon's PR #6445. nTxFee is defined in main.cpp and my LogPrintf() is also in main.cpp. Any idea of a suitable macro. I'm compiling in Linux
 7 2015-07-24 08:04:57 <CodeShark> you can always use a stringstream :)
 8 2015-07-24 08:05:34 <CodeShark> stringstream ss; ss << myInt; printf("%s", ss.str().c_str());
 9 2015-07-24 08:06:09 <venzen> thanks CodeShark, let me try that
10 2015-07-24 08:06:20 <jeroen_> Hi!
11 2015-07-24 08:06:30 <jeroen_> Is there a BIP for the LN SIGHASH_NOINPUT?
12 2015-07-24 08:07:01 <venzen> i see nTxFee is cast as 'CAmount& nTxFee' - not sure what type CAmount effects...
13 2015-07-24 08:08:16 <jeroen_> Sorry I'll ask in lightning-dev
14 2015-07-24 08:23:07 <wumpus> venzen: for LogPrintf you don't need any size specifiers
15 2015-07-24 08:23:21 <wumpus> venzen: as said, we don't use the OS' underlying printf implementation in bitcoin core
16 2015-07-24 08:24:00 <wumpus> %d will work for any integer
17 2015-07-24 08:24:10 <Luke-Jr> %s works for any type I think
18 2015-07-24 08:24:21 <Luke-Jr> although it prints bools as true/false instead of 1/0 :p
19 2015-07-24 08:24:31 <wumpus> not sure of that, but you'll at most get a runtime error, no memory corruption or worse
20 2015-07-24 08:25:48 <jonasschnelli> %s for any type...? Maybe depends on your compiler if he can cast a primitive internaly to a c_str?
21 2015-07-24 08:26:01 <wumpus> no, it doesn't depend on your compiler
22 2015-07-24 08:26:18 <Luke-Jr> jonasschnelli: it's C++ magic
23 2015-07-24 08:26:30 <jonasschnelli> ha.. c++98? or c++11?
24 2015-07-24 08:26:36 <wumpus> the code is in tinyformat.h and is extremely straightforward
25 2015-07-24 08:27:04 <wumpus> c++98 - although it can use c++11 features
26 2015-07-24 08:27:20 <Luke-Jr> some day we'll find out it's consensus-critical <.<
27 2015-07-24 08:27:41 <Luke-Jr> (I mean, more than the obvious sense)
28 2015-07-24 08:27:41 <wumpus> variadic templates
29 2015-07-24 09:22:56 <wumpus> jonasschnelli: re: 6468 - I still don't really like the fixed-74-bytes solution in base58.h. Can't we just fix the two-argument ret.Decode?
30 2015-07-24 09:23:11 <wumpus> hardcoding a size in a template designed to be generic seems to be self-defeating
31 2015-07-24 09:23:33 <jonasschnelli> hmm... let me have a look at it..
32 2015-07-24 09:23:39 <wumpus> also it'd need to be guaranteed that ret.Decode always reads 74 bytes, never more, never less
33 2015-07-24 09:23:57 <wumpus> ... seems like a  magic value assumption that is very fragile
34 2015-07-24 09:24:41 <wumpus> and passing the end bound to Decode so that it knows what memory area it is allowed to access is more robust, potentially
35 2015-07-24 09:25:27 <jonasschnelli> wumpus: The problem is this: If one used the CBitcoinExtKeyBase() constructor with a invalid base58c encoded extended priv key it will end up in a crash...
36 2015-07-24 09:25:35 <wumpus> it puts the responsibility to check data size / bounds inside the decode function itself, which is where it belongs
37 2015-07-24 09:25:44 <jonasschnelli> we could say one needs to ensure the base58c validity in advance..
38 2015-07-24 09:25:47 <wumpus> doesn't that mean that the Decode function needs to be fixed?
39 2015-07-24 09:25:55 <jonasschnelli> wumpus: Yes.
40 2015-07-24 09:26:07 <jonasschnelli> fixing the decode function would make more sense.
41 2015-07-24 09:26:11 <wumpus> right :)
42 2015-07-24 09:26:18 <jonasschnelli> Agreed. :)
43 2015-07-24 09:26:41 <jonasschnelli> It should return a boolean and not crash in terms of a input vector with a differenz size.
44 2015-07-24 09:26:53 <jonasschnelli> Let me fix this.
45 2015-07-24 09:28:16 <jonasschnelli> (git stash and git branch is cool, but having multiple git clones is the most powerful solution if you like to switch between multiple work-in-progress branches)
46 2015-07-24 09:56:06 <wumpus> agree, I have many checkouts of bitcoin/bitcoin as well - can be easier than checking everything in and moving to another branch all the time
47 2015-07-24 11:06:39 <jonasschnelli> wumpus: i think the size check in base58.h makes sense.
48 2015-07-24 11:06:54 <jonasschnelli> otherwise you need to pass a std::vector<unsigned char, zero_after_free_allocator<unsigned char> >  to Decode
49 2015-07-24 11:07:13 <jonasschnelli> it like to keep the pass var to unsigned char code[74]
50 2015-07-24 11:07:29 <jonasschnelli> this would mean Decode has no chance to detect the size of the buffer
51 2015-07-24 11:08:10 <jonasschnelli> passing a std::vector<unsigned char> would mean to first cast/convert the vchData
52 2015-07-24 11:08:29 <jonasschnelli> Therefore: most easy solution sounds after a size check in base58.h
53 2015-07-24 11:08:44 <jonasschnelli> And we already have the size there: typedef CBitcoinExtKeyBase<CExtKey, 74, CChainParams::EXT_SECRET_KEY> CBitcoinExtKey;
54 2015-07-24 11:08:47 <jonasschnelli> (mind the 74)
55 2015-07-24 11:11:30 <wumpus> jonasschnelli: why not just keep passing two pointers?
56 2015-07-24 11:11:48 <jonasschnelli> second for the size?
57 2015-07-24 11:11:53 <wumpus> jonasschnelli: or a pointer and a size_t
58 2015-07-24 11:12:18 <wumpus> no need to pass a actual vector or instance, it just needs a slice of memory
59 2015-07-24 11:12:51 <jonasschnelli> yeah. But passing a slice of mem always mean to detect its correctness in the calling class (= size check in base58.h)?
60 2015-07-24 11:12:59 <jonasschnelli> s/means
61 2015-07-24 11:13:28 <jonasschnelli> ah. wait. i see your point
62 2015-07-24 11:13:30 <wumpus> no, it does not! slice means a pointer and a size, or a begin+end pointer, the callee knows how large the memory area is
63 2015-07-24 11:13:43 <jonasschnelli> Agreed. Yes. Let me do that.
64 2015-07-24 11:13:55 <wumpus> I'm still convinced that the decode function itself should detect those problems...
65 2015-07-24 11:15:06 <jonasschnelli> Yes. Right.
66 2015-07-24 11:17:37 <wumpus> jonasschnelli: LOL
67 2015-07-24 11:17:46 <jonasschnelli> what? :)
68 2015-07-24 11:17:46 <wumpus> jonasschnelli: why are we thinking so difficult
69 2015-07-24 11:18:09 <jonasschnelli> (now he comes with a very simple solution.. sure)
70 2015-07-24 11:18:12 <wumpus> jonasschnelli: you have a *Size* attribute in CBitcoinExtKeyBase
71 2015-07-24 11:18:20 <wumpus> jonasschnelli: so yes, it makes sense to compare there
72 2015-07-24 11:18:28 <wumpus> compare against Size, not against 74, and it's all ok
73 2015-07-24 11:18:48 <jonasschnelli> Yes. Why not. :)
74 2015-07-24 11:19:11 <jonasschnelli> The 74 will move into a const the other PR (don't have the #  right now)
75 2015-07-24 11:19:24 <wumpus> but inside the template it is already a const
76 2015-07-24 11:19:46 <jonasschnelli> wumpus: yeah. Just to remove the hardcoded 74
77 2015-07-24 11:19:54 <wumpus> oh you mean in 'typedef CBitcoinExtKeyBase<CExtKey, 74, CChainParams::EXT_SECRET_KEY> CBitcoinExtKey;'
78 2015-07-24 11:20:04 <jonasschnelli> yeah. The 74 there.
79 2015-07-24 11:20:21 <wumpus> ok, make sense. But inside the template you should definitely use Size.
80 2015-07-24 11:21:25 <jonasschnelli> wumpus: yes. I don't know why i didn't used Size at first place.
81 2015-07-24 11:21:42 <wumpus> I didn't know it existed, otherwise I'd have commented that
82 2015-07-24 13:33:48 <wumpus> CiPi: not here
83 2015-07-24 13:34:16 <CiPi> Yeah...
84 2015-07-24 13:44:41 <teward> and not in the Ubuntu channels either
85 2015-07-24 18:53:02 <anon18109851> What's the appropriate place to comment on BIP-100? The dev-list thread is dead. Also, where's the most up to date draft? I'm seeing conflicting information.
86 2015-07-24 19:08:08 <drazisil> anon18109851: as far as I can tell it's https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/
87 2015-07-24 20:18:04 <jtimon> ping cfields