<div dir="ltr">Actually, I take that back. If it is a worry that the internal representation will change, it seems also unsafe to be casting the sixteen bytes as a uuid_t when copying into them with uuid_copy(). If the internal representation changed to add a new field, then there would be a buffer overrun when using uuid_copy(). If the internal representation changed the order of the bytes, uuid_copy() would propagate that to the on-disk structure and yield compatibility issues. <br><br>Perhaps it would be safer to store the UUIDs on disk as a string. Or add to uuid.[ch] a function to get the raw bytes in a fixed order suitable for storing on disk? <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 11:52 AM John Dorminy <<a href="mailto:jdorminy@redhat.com" target="_blank">jdorminy@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">That does make sense. May I request, then, using UUID_SIZE instead of 16? Perhaps with a compile-time assertion that UUID_SIZE has not change from 16?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 11:10 AM Hannes Reinecke <<a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/2/20 4:53 PM, John Dorminy wrote:<br>
> I'm worried about hardcoding uuid members as u8[16].<br>
> <br>
> May I ask why you're not using uuid_t to define it in the on-disk <br>
> structure? It would save the casting of the uuid members to (uuid_t *) <br>
> every time you use a uuid.h function.<br>
> <br>
> Possibly it is customary to use only raw datatypes on disk rather than <br>
> opaque types like uuid_t, I'm not sure. But in that case, perhaps using <br>
> the named constant UUID_SIZE instead of 16 would make the meaning clearer?<br>
> <br>
I prefer to use absolute types (like __u8) when describing the on-disk <br>
format.<br>
When using opaque types like uuid_t there always is the risk that the <br>
internal representation will change, leading to an involuntary change of <br>
the on-disk format structure and subsequent compability issues.<br>
<br>
Cheers,<br>
<br>
Hannes<br>
-- <br>
Dr. Hannes Reinecke            Teamlead Storage & Networking<br>
<a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a>                               +49 911 74053 688<br>
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg<br>
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer<br>
<br>
</blockquote></div>
</blockquote></div>