02:28:32 <m-relay> <x​mrack:monero.social> When I try to compile monero with 
02:28:33 <m-relay> <x​mrack:monero.social> “make fuzz”
02:28:35 <m-relay> <x​mrack:monero.social> I get the following errors
02:28:37 <m-relay> <x​mrack:monero.social> https://pastebin.com/u2gv4xdx
02:29:06 <m-relay> <x​mrack:monero.social> Anyone have an idea why?
07:57:25 <m-relay> <0​xfffc:monero.social> Boost uuid had a major update in 1.86 and the underlying data structure has been changed from [1] to [2, 3]. I think that is the reason why we get serialization error. Should be quite easy to fix. Will take a look at it. 
07:57:27 <m-relay> <0​xfffc:monero.social> 1. https://github.com/boostorg/uuid/blob/beeaab4758c2f48d0451c759a600b34116c20906/include/boost/uuid/uuid.hpp#L148
07:57:29 <m-relay> <0​xfffc:monero.social> 2. https://github.com/boostorg/uuid/blob/02c82cea9c82e4fdbc32b58e5a2e9f97dfc50755/include/boost/uuid/uuid.hpp#L44
07:57:31 <m-relay> <0​xfffc:monero.social> 3. https://github.com/boostorg/uuid/blob/02c82cea9c82e4fdbc32b58e5a2e9f97dfc50755/include/boost/uuid/uuid.hpp#L96
16:02:33 <m-relay> <j​effro256:monero.social> Yeah build issues failing on MacOS since apparently UUID is not a POD type anymore
16:14:50 <m-relay> <s​yntheticbird:monero.social> who the hell decided to break the saint rule of UUID = 128 bit integer = 16 bytes
16:15:11 <m-relay> <s​yntheticbird:monero.social> Big L from boost on this one
17:20:18 <selsta> ty jeffro256 will test if it builds
18:21:36 <selsta> jeffro256: seems there are still some compiler errors on macOS https://github.com/monero-project/monero/actions/runs/10529735156/job/29178145531?pr=9450
20:12:07 <m-relay> <j​effro256:monero.social> okay working on further fixes. I wish I had a Mac to test it on
20:12:27 <m-relay> <j​effro256:monero.social> I guess I could update my system's boost to 1.85 or compile it myself and point monero to it
20:12:47 <m-relay> <j​effro256:monero.social> vtnerd: do the bytes spans NEED to check that there's no padding ?
20:12:59 <m-relay> <j​effro256:monero.social> Especially the unmutable ones
20:13:43 <m-relay> <j​effro256:monero.social> I think it would be fine to simply check trivially_copyable for the mutable spans, and let the applications downstream decide if they actually need types with no padding
20:15:25 <m-relay> <j​effro256:monero.social> Also I caught and removed three times where the private view key would get dumped to the log on point deserialization failure
20:17:05 <m-relay> <0​xfffc:monero.social> FYI You don't need mac, you can use guix script to build with whatever version of boost you like.
20:19:24 <m-relay> <j​effro256:monero.social> True
20:19:31 <m-relay> <j​effro256:monero.social> Also I think normal depends does this too
22:04:17 <m-relay> <v​tnerd:monero.social> If the spans have padding it could cause platform issues as the padding could differ. Otherwise it shouldn't really matter
22:32:52 <m-relay> <j​effro256:monero.social> During serialization?
23:05:09 <m-relay> <j​effro256:monero.social> Because if so, we should assert it there IMO
23:05:19 <m-relay> <j​effro256:monero.social> span should just guarantee memory safety
23:12:35 <m-relay> <v​tnerd:monero.social> Span has a function to reinterpret a class as bytes. It checks for padding as they could cause problems in typical usage