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. 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? On Thu, Apr 2, 2020 at 11:52 AM John Dorminy wrote: > 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? > > On Thu, Apr 2, 2020 at 11:10 AM Hannes Reinecke wrote: > >> On 4/2/20 4:53 PM, John Dorminy wrote: >> > I'm worried about hardcoding uuid members as u8[16]. >> > >> > May I ask why you're not using uuid_t to define it in the on-disk >> > structure? It would save the casting of the uuid members to (uuid_t *) >> > every time you use a uuid.h function. >> > >> > Possibly it is customary to use only raw datatypes on disk rather than >> > opaque types like uuid_t, I'm not sure. But in that case, perhaps using >> > the named constant UUID_SIZE instead of 16 would make the meaning >> clearer? >> > >> I prefer to use absolute types (like __u8) when describing the on-disk >> format. >> When using opaque types like uuid_t there always is the risk that the >> internal representation will change, leading to an involuntary change of >> the on-disk format structure and subsequent compability issues. >> >> Cheers, >> >> Hannes >> -- >> Dr. Hannes Reinecke Teamlead Storage & Networking >> hare@suse.de +49 911 74053 688 >> SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg >> HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer >> >>