--- Log opened Thu Oct 05 00:00:48 2023
00:05 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
00:09 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Ping timeout: 255 seconds]
00:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
00:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
00:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
00:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 260 seconds]
00:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
00:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 248 seconds]
01:00 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
01:04 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
01:05 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
01:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
01:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
01:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
01:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
01:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
02:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
02:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
02:10 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
02:21 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 272 seconds]
02:27 -!- MatrixBot1234561 [~matrixbot@2001:bc8:1824:bc3::1] has quit [Quit: Bridge terminating on SIGTERM]
02:33 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
02:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
02:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
02:56 -!- johnzweng [~johnzweng@zweng.at] has quit [Quit: Leaving...]
02:59 -!- johnzweng [~johnzweng@zweng.at] has joined #bitcoin-core-pr-reviews
02:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
03:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
03:16 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
03:28 -!- gordon16 [~gordon@mob-194-230-148-74.cgn.sunrise.net] has joined #bitcoin-core-pr-reviews
03:32 -!- gordon16 [~gordon@mob-194-230-148-74.cgn.sunrise.net] has quit [Client Quit]
04:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
04:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 255 seconds]
04:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-pr-reviews
04:41 -!- pablomartin [~pablomart@217.146.93.22] has joined #bitcoin-core-pr-reviews
04:51 -!- pablomartin [~pablomart@217.146.93.22] has quit [Ping timeout: 240 seconds]
05:16 -!- pablomartin [~pablomart@185.216.146.240] has joined #bitcoin-core-pr-reviews
05:53 -!- pablomartin [~pablomart@185.216.146.240] has quit [Ping timeout: 255 seconds]
06:05 -!- johnzweng [~johnzweng@zweng.at] has quit [Ping timeout: 246 seconds]
06:17 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
06:20 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Remote host closed the connection]
06:39 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
06:41 -!- brunoerg [~brunoerg@2804:1600:115:e500:70c4:8bf5:6e57:a222] has joined #bitcoin-core-pr-reviews
07:32 -!- pablomartin [~pablomart@217.146.93.22] has joined #bitcoin-core-pr-reviews
07:38 -!- brunoerg [~brunoerg@2804:1600:115:e500:70c4:8bf5:6e57:a222] has quit [Remote host closed the connection]
08:34 -!- maxedwards [~maxedward@90.203.107.196] has joined #bitcoin-core-pr-reviews
08:50 -!- pablomartin4btc [~pablomart@185.216.146.241] has joined #bitcoin-core-pr-reviews
08:51 -!- pablomartin [~pablomart@217.146.93.22] has quit [Ping timeout: 240 seconds]
08:57 -!- pablomartin4btc [~pablomart@185.216.146.241] has quit [Ping timeout: 255 seconds]
09:30 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:b:f00a] has joined #bitcoin-core-pr-reviews
09:52 -!- vmammal [~vmammal@162.250.26.106] has joined #bitcoin-core-pr-reviews
09:57 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:e1b1:e648:f55b:1feb] has joined #bitcoin-core-pr-reviews
10:00 < stickies-v> #startmeeting
10:00 < dberkelmans> hi
10:00 < maxedwards> hello!
10:00 < vmammal> hi
10:01 < glozow> hi
10:01 < stickies-v> hello everyone! welcome back to the second meeting about https://bitcoincore.reviews/28107
10:01 < maxedwards> looking forward to learning the answers to these questions from you experienced people!
10:02 < stickies-v> yesterday we focused on questions 1-9 which dealt with the conceptual aspects of type safety and wtxid/txid
10:02 < stickies-v> today we'll be diving more into the code of the PR, so expect a more technical discussion
10:02 < stickies-v> maxedwards: ooh we're definitely all here to learn though! the discussion is the most important bit
10:03 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:03 < lightlike> hi
10:03 < stickies-v> if anyone's here lurking - feel free to say hi so we know you're here!
10:04 < stickies-v> alright let's kick it off with the first question
10:04 < stickies-v> 10. How is `transaction_identifier` able to subclass `uint256`, given that, in C++, integers are types and not classes?
10:04 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:b:f00a] has quit [Remote host closed the connection]
10:04 < maxedwards> I believe that uint256 is not a built in type
10:05 < maxedwards> and just a normal class
10:06 < vmammal> maxedwards +1
10:06 < stickies-v> yes correct maxedwards! we have quite a few places that rely on 256bit hash digests so having a dedicated type for it seems helpful
10:06 < maxedwards> `class uint160 : public base_blob<160>`
10:06 < maxedwards> ignore sorry, wrong code!
10:06 < lightlike> i think c++ doesn't have a 256 bit built-in type we could use - even if we wanted to.
10:07 < maxedwards> `class uint256 : public base_blob<256>`
10:07 < stickies-v> so can we assume that a uint256 behaves otherwise the same as, for example a uint64_t?
10:07 < stickies-v> maxedwards: correct!
10:07 < stickies-v> lightlike: i don't think so either
10:08 < larryruane_> I don't think it supports addition (for example)
10:09 < sipa> it used to, until arith_uint256 got split from uint256
10:09 < stickies-v> larryruane_: yeah correct, it doesn't implement a lot of the integer operations. Actually, the only defined operators are `operator==`, `operator!=` and `operator<`
10:09 < stickies-v> (which... may seem familiar if you've seen the `transaction_identifier` code
10:10 < stickies-v> sipa: oh - any background on when/why that got split?
10:10 < maxedwards> it looks like now it supports GetHex, SetHex and ToString
10:11 < glozow> we don't want to do arithmetic operations on hash identifiers?
10:11 < maxedwards> Can someone point me to where the == operator is set?
10:12 < larryruane_> ah I just noticed `GetHex()` and `ToString()` are the same, I always wondered about that (should have just looked it up)
10:12 < stickies-v> glozow: having a `hash256` type or something would be a bit more intuitive than making `uint256` not an int, too :-D but it's probably way less code churn that way
10:12 < stickies-v> maxedwards: https://github.com/bitcoin/bitcoin/blob/6e5cf8e95391cd9a8bfc0c357e8a6f3963bad4b4/src/uint256.h#L56
10:13 < stickies-v> launching the next one already but we can keep conversation on previous questions going
10:13 < maxedwards> ah yes I see them, thanks
10:13 < stickies-v> 11. Why does `transaction_identifier` subclass `uint256` instead of being a completely new type?
10:13 < sipa> stickies-v: https://github.com/bitcoin/bitcoin/pull/5490
10:14 < sipa> in short, because arithmetic operations on hashes make no sense - they only matter in the context of PoW, but hashes (which is what uint256 is effectively used for) are used for many more things than that
10:14 < maxedwards> I think this was touched on yesterday and the suggestion was that you could migrate in stages
10:14 < sipa> going back even further, all of uint256 and arith_uint256 was implemented using OpenSSL's bignum
10:15 < stickies-v> ooh, and then it became its own type when moving to libsecp256k1?
10:15 < sipa> no, that's all unrelated
10:15 < larryruane_> we don't depend on OpenSSL at all any more, do we?
10:15 < sipa> oh right, it was one of the things we depended on OpenSSL for, but there were many others
10:16 < sipa> CScriptNum too was introduced to avoid bignum dependency in the script interpreter
10:16 < stickies-v> maxedwards: and specifically, what is it about subclassing that allows us to migrate in stages?
10:16 < sipa> the BIP70 payment protocol was another openssl dependency
10:16 < sipa> and SSL-encrypted RPC is also something we used to have
10:17 < maxedwards> I think that you could pass a wtxid to a function that takes a uint256
10:17 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
10:18 < maxedwards> so you can leave a lot of code as is?
10:19 < stickies-v> yeah, we can use implicit conversions to leave code that is expecting a `uint256` unchanged until it's an appropriate time to move it to a more strict `Txid` or `Wtxid` type
10:19 < larryruane_> stickies-v: if B is a subclass of A, then you can pass a B to a function that takes an A and it works... you'd think that would be a type mismatch but it's not!
10:19 < stickies-v> i've learned to stop thinking and rely on cppreference instead :-D 
10:19 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has joined #bitcoin-core-pr-reviews
10:20 < sipa> cppreference is great
10:20 < larryruane_> but usually aren't some of A's methods virtual? (so B can have its own implementation?) Not true of Txid and uint256
10:21 < stickies-v> `base_blob` (which is `uint256`'s parent) and `transaction_identifier` are templated classes
10:21 < stickies-v> templated methods cannot be virtual
10:21 < sipa> this is not a traditional situation where type distinction matters
10:21 < sipa> because the operations on a Txid and WTxid are the same
10:21 < larryruane_> stickies-v: +1 thanks didn't know that
10:21 < larryruane_> sipa: +1 thanks
10:21 < sipa> the goal isn't to catch runtime mismatches for operations that don't apply in a way we can figure out at compile time
10:22 < maxedwards> even if there were overridden methods, you could still pass it couldn't you?
10:22 < sipa> rather, it's us deliberately making two types that are operationally compatible into separate ones, to make sure one doesn't get used in the wrong place
10:23 < stickies-v> sipa: it's not really the point larryruane_ was trying to make I think, but have templated virtual methods could be helpful here though, I think
10:23 < stickies-v> atm we have to redefine all the `operator{==, !=, <}` methods on `transaction_identifier`
10:23 < stickies-v> but with a `virtual Compare` method that could be avoided
10:24 < sipa> i don't see how anything virtual is useful here
10:25 < stickies-v> maxedwards: could you elaborate a bit on that?
10:25 < sipa> you could use the curious self-referencial template trick to do the same thing without needing the runtime overhead of a virtual function call
10:26 < sipa> template<T> class transaction_identifier { bool operator==(const T& other) { ... } }
10:26 < sipa> class Txid : public transaction_identifier<Txid> { ... }
10:26 < maxedwards> It wasn't specific to this codebase and more of a C++ question about passing a subclass to a function that takes the superclass but I can look it up myself to save time.
10:27 < stickies-v> well but what I'm trying to avoid is having to redefine the `operator` methods on `transaction_identifier` because i think the ones on `uint256` work just fine, except for the fact that they call `a.Compare...` and we need to use the `transaction_identifier::Compare` method instead of the `uint256` one?
10:28 < stickies-v> maxedwards: yeah my understanding is that would get implicitly converted to the superclass
10:28 < sipa> stickies-v: you don't need virtual functions for that (and generally don't want to, as they have a performance cost)
10:28 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:29 < sipa> the point is that these "distinct" Compare functions aren't actually operationally distinct, they just operate on different types
10:31 < sipa> but i'll need to look at the actual code to be more concrete
10:31 < stickies-v> maybe i'm confused by "operationally", but they are distinct though?
10:31 < sipa> they're just comparing the bytes, no?
10:31 < sipa> the distinction is in which types they accept
10:31 < stickies-v> yes, beyond the static_assert they are identical
10:31 < sipa> right, exactly
10:32 < sipa> the static_assert doesn't exist at runtime
10:32 < stickies-v> right okay, I see
10:33 < larryruane_> i never thought a `static_assert` could be inside an `if`, that's cool
10:33 < stickies-v> thanks, i'll look into the self referential template trick after the meeting, that looks curious!
10:33 < sipa> larryruane_: in a normal if, it doesn't matter whether it's inside or outside
10:33 < sipa> in a constexpr if, where one branch can be discarded at compile-time, things are different
10:34 < larryruane_> yes exactly so i'm used to seeing it outside ... yes i wasn't aware of `constexpr if`
10:34 < sipa> larryruane_: cppreference to the rescue :p
10:35 < larryruane_> on my next extended vacation i'm going to curl up with cppreference
10:36 < stickies-v> very interesting rabbit hole, but regardless i'll pop the next question already for folks dying to answer:
10:36 < stickies-v> 13. [`transaction_identifier::Compare`] is defined to return a `int`, yet `reinterpret_cast<const uint256&>` is used in the return statement. Is this correct, and if so, why? Why `reinterpret_cast` instead of another cast, such as `static_cast`?
10:36 < stickies-v> (link: https://github.com/bitcoin-core-review-club/bitcoin/commit/28f9ff3d5416407d3c6d5374f6fc3c2767f4a7f3#diff-f3d91988bf7d98529d638fa829dc3fab695be002305a7614eaaeb283d4fb8101R39)
10:36 < maxedwards> I have no idea
10:37 < stickies-v> hint: think of your order of operations
10:38 < sipa> stickies-v: it's not converting the `int`, though, it's converting the `this` object on which the operation is invoked
10:39 < stickies-v> sipa: bingo!
10:39 < larryruane_> can you go over that again? I'm not following
10:40 < stickies-v> we're just casting our `transaction_identifier` into a `uint256`, and then using the `uint256::Compare` method, which does indeed return an `int`
10:40 < larryruane_> i think i see, if we didn't do the `reinterpret_cast` it would be a recursive call?
10:41 < sipa> did you mean a recursive call?
10:41 < stickies-v> larryruane_: in `return reinterpret_cast<const uint256&>(*this).Compare(other);`, I was at first confused as to why we were casting the return value into a `uint256` when the function signature specifies an `int` return type
10:41 < stickies-v> until I realized that the `reinterpret_cast` is not operating on the return value of `Compare`, but on `(*this)`
10:42 < larryruane_> well i saw the `.Compare()` which returns an int, so that didn't confuse me
10:42 < stickies-v> but yes, without the cast it would be a recursive call
10:42 < larryruane_> interesting, i just removed the `reinterpret_cast<const uint256&>` (from before (*this)) and it compiles
10:42 < stickies-v> i guess i'm just easily bamboozled :(
10:43 < larryruane_> well never mind, it probably compiles but will infinite-loop (until stack overflow) maybe?
10:44 < sipa> larryruane_: indeed
10:44 < larryruane_> (i was expecting it wouldn't compile)
10:44 < sipa> recursive calls are not illegal
10:44 < sipa> infinite loops however are, but the compiler may not be smart enough to figure out that this is one
10:45 < stickies-v> so, why `reinterpret_cast` instead of another cast, such as `static_cast`?
10:45 < sipa> or, if it smart enough to figure out this gives rise to an infinite loop, it could assume it'd never be invoked
10:45 < larryruane_> stickies-v: more efficient? `reinterpret_cast` has no runtime overhead (but `static_cast` could)?
10:46 < sipa> a static cast would construct a new uint256 object, maybe (not actually sure if that applies to reference types)
10:47 < larryruane_> hmm changing that to `static_cast` compiles and the binary is exactly the same size (not sure if that means the code is the same tho)
10:47 < vmammal> stickies-v stackoverflow says static cast is unnecessary when casting up an inheritance hierarchy toward the base class
10:48 < maxedwards> larryruane_ interesting that it's the same size
10:48 < stickies-v> larryruane_: interestingly, my laptop just crashed while trying to compile without the reinterpret_cast 😅
10:49 < larryruane_> crashed, wow
10:49 < stickies-v> Ran out of memory and couldn't recover
10:49 < larryruane_> oh because it's constexpr, so the infinite recursion is at compile time!! 
10:49 < maxedwards> I wonder if the compiler is clever enough to know in this direction a static_cast could be implemented as a reinterpret_cast?
10:49 < larryruane_> my system (ubuntu) doesn't
10:50 < larryruane_> seems really bad that can crash your entire laptop (not just OOM the compiler)
10:51 < stickies-v> i'm on macos. not 100% it's related but this is the first time it happened. will reproduce when the meeting's over
10:52 < stickies-v> 14.  Is the `has_witness` template parameter used for purposes other than type differentiation in `transaction_identifier`?
10:52 < stickies-v> (link: https://github.com/bitcoin-core-review-club/bitcoin/commit/28f9ff3d5416407d3c6d5374f6fc3c2767f4a7f3#diff-f3d91988bf7d98529d638fa829dc3fab695be002305a7614eaaeb283d4fb8101R17)
10:53 < vmammal> stickies-v no
10:54 < sipa> larryruane_: the constexpr will not cause recursion at compile time
10:54 < sipa> i think
10:54 < stickies-v> vmammal: correct!
10:54 < stickies-v> What are the limitations of this approach? Do you see alternatives?
10:54 < vmammal> nit: does anyone else prefer the `is_witness` naming style over `has_witness` ?
10:54 < larryruane_> by this approach, what do  you mean, the entire PR? or something more specific?
10:55 < stickies-v> I mean using `template <bool has_witness>`
10:55 < maxedwards> vmammal: no because it's more than just the witness
10:56 < larryruane_> i guess an alternative would be to have `Txid` and `Wtxid` both subclass `uint256` directly ... but that would duplicate code
10:56 < stickies-v> larryruane_: yeah that would probably not pass review :-D 
10:56 < vmammal> maxedwards fair
10:57 < vmammal> is there a performance cost to templating?
10:57 < larryruane_> vmammal: I think i prefer the existing `has_witness` because a transaction ID doesn't include a witness at all ever
10:57 < stickies-v> vmammal: compile time yes, runtime i don't think so?
10:58 < sipa> templating is effectively equivalent to the compiling generating the code for you
10:58 < larryruane_> vmammal: i guess very indirectly, because templating can lead to executable bloat (if the alternative isn't duplicating code), and that could lead to more code cache misses
10:59 < stickies-v> one thought I had (but it's almost definitely premature optimization) is that it's not guaranteed that we'll never have more than 2 types of tx identifiers, so then templating based on e.g. an enum instead of a bool could make sense
11:00 < larryruane_> the C codebase i used to work on heavily used c-preprocessor templating, which was actually pretty cool! (so c++ isn't needed to implement this concept) ... it confused IDEs however
11:00 < stickies-v> and i think when we don't have `transaction_identifier` subclass `uint256` (but wrap it instead) it'll be feasible to avoid templating too, but i didn't fully work that out either so could be wrong
11:01 < stickies-v> alright that's all the time we have for today folks
11:01 < stickies-v> #endmeeting
11:01 < maxedwards> stickies-v: how distruptive would moving to enum for the template be in the future?
11:01 < maxedwards> ah missed the bell!
11:01 < stickies-v> maxedwards: not very, I think
11:01 < stickies-v> given than they're just typedefs
11:01 < maxedwards> Many thanks for hosting stickies-v!
11:02 < dberkelmans> Thanks all, I've still got a lot of c++ to explore/learn
11:02 < maxedwards> and to everyone else for sharing
11:02 < stickies-v> *given that `Txid` and `Wtxid` are what's actually used, and they're typedefs, so updating the implementation in `transaction_identifier.h` shouldn't affect any code that uses it
11:02 < maxedwards> I think this is my favourite way to learn a language
11:03 < maxedwards> stickies-v: I assumed the same
11:03 < larryruane_> thanks, @stickies-v great meeting, thanks for hosting!
11:03 < stickies-v> hope y'all learned something - appreciate you sticking with us for the full 2 days!
11:03 < maxedwards> learnt a lot
11:04 < stickies-v> alright and now it's time to crash my laptop again (potentially)
11:04 < larryruane_> just to follow up on something related to that (that i brought up yesterday), it was mentioned that making `Txid` and `Wtxid` both *wrap* a `uint256` would be very disruptive,
11:05 < larryruane_> but one of those is much more prevalant in our code than the other, I think `txid` ... so maybe that one could continue to be a `uint256` like today, but there could be a `Wtxid` that wraps a `uint256` ... that would still be type-safe between the two ... wonder if that would work well (not be too disruptive touching many lines) ... I may play around with that idea
11:06 < glozow> thanks stickies-v!
11:07 < stickies-v> larryruane_: interesting idea
11:08 < stickies-v> larryruane_: sipa: I ran make check instead of make. Compilation is fine, didn't realize I started the unit tests too, and they OoM'd me.
11:13 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:e1b1:e648:f55b:1feb] has quit [Quit: Client closed]
11:23 -!- vmammal [~vmammal@162.250.26.106] has quit [Quit: Connection closed]
11:45 < maxedwards> larryruane_ I just looked at the assembly for `reinterpret_cast` vs `static_cast` casting from derived to base class and it's exactly the same so no wonder your binary came out as exactly the same size.
11:49 < maxedwards> both for x86 and arm
11:51 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
11:52 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Client Quit]
11:52 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
11:56 < maxedwards> here is the sample code I wrote on compiler explorer: https://godbolt.org/z/4ehThveeq
11:57 -!- __gotcha [~Thunderbi@94.105.116.209.dyn.edpnet.net] has quit [Ping timeout: 255 seconds]
12:16 < larryruane_> stickies-v: oh makes sense thanks
12:17 < sipa> i think the code should use static_cast
12:17 < sipa> reinterpret_cast is the "more dangerous" one, and apparently it's not needed here
12:18 -!- maxedwards [~maxedward@90.203.107.196] has quit [Quit: Connection closed]
12:19 < stickies-v> sipa: that's how it was implemented originally, but then changed after this comment: https://github.com/bitcoin/bitcoin/pull/28107#discussion_r1285978619
12:19 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
12:20 < sipa> ha, interesting
12:20 < sipa> ok
12:21 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
12:21 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:32 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:36 -!- maxedwards [~maxedward@90.203.107.196] has joined #bitcoin-core-pr-reviews
12:47 -!- maxedwards [~maxedward@90.203.107.196] has quit [Quit: Connection closed]
12:56 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
13:03 -!- pablomartin4btc [~pablomart@217.146.93.23] has joined #bitcoin-core-pr-reviews
13:16 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
13:21 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
13:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has joined #bitcoin-core-pr-reviews
13:41 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has quit [Remote host closed the connection]
13:57 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has joined #bitcoin-core-pr-reviews
14:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has quit [Ping timeout: 240 seconds]
14:05 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
14:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has joined #bitcoin-core-pr-reviews
14:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has quit [Remote host closed the connection]
15:19 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has joined #bitcoin-core-pr-reviews
15:36 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has quit [Remote host closed the connection]
15:47 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has joined #bitcoin-core-pr-reviews
15:50 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:51 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has quit [Ping timeout: 240 seconds]
16:00 -!- brunoerg [~brunoerg@187.183.43.149] has joined #bitcoin-core-pr-reviews
16:21 -!- brunoerg [~brunoerg@187.183.43.149] has quit [Remote host closed the connection]
16:59 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has quit [Read error: Connection reset by peer]
16:59 -!- grettke_ [~grettke@065-026-198-174.biz.spectrum.com] has joined #bitcoin-core-pr-reviews
17:13 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has joined #bitcoin-core-pr-reviews
17:17 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has quit [Ping timeout: 240 seconds]
17:24 -!- grettke_ [~grettke@065-026-198-174.biz.spectrum.com] has quit [Quit: grettke_]
17:56 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has joined #bitcoin-core-pr-reviews
17:59 -!- brunoerg [~brunoerg@179.191.241.108] has joined #bitcoin-core-pr-reviews
18:19 -!- brunoerg [~brunoerg@179.191.241.108] has quit [Ping timeout: 255 seconds]
18:51 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-pr-reviews
18:59 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 240 seconds]
19:35 -!- puchka [~puchka@185.203.122.42] has quit [Ping timeout: 258 seconds]
19:37 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-pr-reviews
19:41 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 240 seconds]
20:11 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-pr-reviews
20:17 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 272 seconds]
20:45 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-pr-reviews
20:49 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 240 seconds]
21:28 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
21:47 -!- pablomartin4btc [~pablomart@217.146.93.23] has quit [Ping timeout: 255 seconds]
21:55 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-pr-reviews
22:00 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 258 seconds]
22:01 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-pr-reviews
22:11 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 272 seconds]
22:40 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-pr-reviews
22:45 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 258 seconds]
23:13 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-pr-reviews
23:18 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 264 seconds]
23:45 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-pr-reviews
23:50 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 272 seconds]
--- Log closed Fri Oct 06 00:00:48 2023