On Thu, Aug 22, 2019 at 01:43:05AM +0300, Maxim Levitsky wrote: > On Tue, 2019-08-20 at 20:01 +0200, Max Reitz wrote: > > On 14.08.19 22:22, Maxim Levitsky wrote: > > > With upcoming key management, the header will > > > need to be stored after the image is created. > > > > > > Extracting load header isn't strictly needed, but > > > do this anyway for the symmetry. > > > > > > Also I extracted a function that does basic sanity > > > checks on the just read header, and a function > > > which parses all the crypto format to make the > > > code a bit more readable, plus now the code > > > doesn't destruct the in-header cipher-mode string, > > > so that the header now can be stored many times, > > > which is needed for the key management. > > > > > > Also this allows to contain the endianess conversions > > > in these functions alone > > > > > > The header is no longer endian swapped in place, > > > to prevent (mostly theoretical races I think) > > > races where someone could see the header in the > > > process of beeing byteswapped. > > > > The formatting looks weird, it doesn’t look quite 72 characters wide... > > (what commit messages normally use) > Could you elaborate on that? I thought that code should not > exceed 80 character limit.
Code itself should be wrapped at 80 chars, but it is common for commit messages to use 72 chars wrapping. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|