00:16 <prayank> TallTim: If you are curious about meetup details they will be shared on website. If you are curious about the article it just highlights issues with dependency on few people and one repository.

00:16 <prayank> There is no "rage quit" thing in this, just that I don't want to become another r/bitcoin moon kid with some C++ knowledge. I have my own identity and thoughts.

00:17 <prayank> Organizing a dev meetup because that will help me and everyone involved achive their goals. Mine is to improve Bitcoin doesn't matter if it affects my own life.

00:17 <TallTim> ok thx

03:08 <luke-jr> how does lint-format-strings.py tolerate #23050 ? :/

03:08 <gribble> https://github.com/bitcoin/bitcoin/issues/23050 | log: change an incorrect fee to fee rate, and vice-versa by jonatack · Pull Request #23050 · bitcoin/bitcoin · GitHub

03:08 <luke-jr> it seems to be missing logic for the {} init list with a comma?

03:10 <luke-jr> ah, it was changed after my fetch of it. maybe still should fix the linter anyway?

03:12 <sipa> wouldn't it be better to add __attribute__((format (printf, ...))) or something like that?

03:12 <sipa> GCC/clang have built-in features for testing arguments to printf-like functions

03:13 <sipa> ah, but LogPrintf and friends are less strict than printf is

03:13 <sipa> so that might cause problems

03:14 <sipa> luke-jr: why should it fail?

03:15 <Davidbak> "LogPrintf and friends are less strict than printf is" - is that a good thing? (In what ways is it (are they) less strict?)

03:15 <luke-jr> sipa: it shouldn't fail, but the linter doesn't parse the {} chars

03:15 <sipa> davidbak: they're C++, so they can use the type system instead

03:16 <luke-jr> sipa: so it thinks a comma inside them is a param separator for the func

03:16 <sipa> LogPrintf("%i", x) works for any kind of integer type x

03:16 <sipa> regardless of its size

03:16 <luke-jr> LogPrintf("%s", CFeeRate{1,2}) lint-fails at the moment claiming 2 params for the one %2

03:16 <sipa> davidbak: look at src/tinyformat.h

03:16 <luke-jr> %s*

03:16 <Davidbak> so ... they're _more_ strict? Because I thought they used tinyformat?

03:17 <luke-jr> davidbak: if you feed the wrong size integer to %i, printf explodes :p

03:18 <Davidbak> oh I guess it is a point-of-view thing: I consider tinyformat to be _more_ strict 'cause it'll do the right thing or complain at compile time; printf to be less strict because it'll accept garbage and die at run time. But the _other_ POV works too if that's the way you like it.

03:18 <sipa> davidbak: it won't complain at compile time

03:19 <sipa> because the format string is only processed at runtime

03:19 <sipa> and you can still do things like "%li" or "%hi", the h or l is just ignored

03:21 <Davidbak> oh. hmm. maybe it should be revved up to C++17 (does Bitcoin Core accept/require c++17?) and constexpr'd all the way?

03:21 <sipa> we do use C++17 yes

03:21 <Davidbak> guess I thought tinyformat was already there but looking at the code I see not.

03:22 <sipa> it's just C++11 i think

03:24 <Davidbak> yeah I think so. probably not an exploitable security hole though if only used for logging (just a potential reliability issue).

03:24 <Davidbak> never mind what I just said please I didn't think it through

03:25 <luke-jr> speaking of which, someone was complaining about C++17 in #bitcoin earlier

03:25 <luke-jr> s/earlier/nowish/

03:34 <Davidbak> here on libera? (that channel doesn't advertise an archive in its topic, do you know of one? if not, is this c++17 discussion interesting enuf to recap here?)

03:37 <Davidbak> (although I know of one issue right now w.r.t. using constexpr processing for format strings: compile times go way up. So ... nvm for a couple of years, until the compilers get that straightened out ...)