<x​mrack:monero.social> When I try to compile monero with

<x​mrack:monero.social> “make fuzz”

<x​mrack:monero.social> I get the following errors

<x​mrack:monero.social> pastebin.com/u2gv4xdx

<x​mrack:monero.social> Anyone have an idea why?

<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.

<0​xfffc:monero.social> 1. github.com/boostorg/uuid/blob/beeaa…06/include/boost/uuid/uuid.hpp#L148

<0​xfffc:monero.social> 2. github.com/boostorg/uuid/blob/02c82…755/include/boost/uuid/uuid.hpp#L44

<0​xfffc:monero.social> 3. github.com/boostorg/uuid/blob/02c82…755/include/boost/uuid/uuid.hpp#L96

<j​effro256:monero.social> Yeah build issues failing on MacOS since apparently UUID is not a POD type anymore

<s​yntheticbird:monero.social> who the hell decided to break the saint rule of UUID = 128 bit integer = 16 bytes

<s​yntheticbird:monero.social> Big L from boost on this one

ty jeffro256 will test if it builds

jeffro256: seems there are still some compiler errors on macOS github.com/monero-project/monero/ac…10529735156/job/29178145531?pr=9450

<j​effro256:monero.social> okay working on further fixes. I wish I had a Mac to test it on

<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

<j​effro256:monero.social> vtnerd: do the bytes spans NEED to check that there's no padding ?

<j​effro256:monero.social> Especially the unmutable ones

<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

<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

<0​xfffc:monero.social> FYI You don't need mac, you can use guix script to build with whatever version of boost you like.

<j​effro256:monero.social> True

<j​effro256:monero.social> Also I think normal depends does this too

<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

<j​effro256:monero.social> During serialization?

<j​effro256:monero.social> Because if so, we should assert it there IMO

<j​effro256:monero.social> span should just guarantee memory safety

<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