> On Nov 28, 2017, at 10:24 AM, Zachary Turner <ztur...@google.com> wrote: > > > > On Tue, Nov 28, 2017 at 10:18 AM Greg Clayton <clayb...@gmail.com > <mailto:clayb...@gmail.com>> wrote: >> On Nov 27, 2017, at 10:11 PM, Zachary Turner <ztur...@google.com >> <mailto:ztur...@google.com>> wrote: >> >> As an aside, I don't really like this class. For example, You can currently >> assign a UUID[16] to a UUID[20]. That doesn't make a lot of sense to me. > > What about an invalid UUID[0] being assigned with a valid UUID[16] or > UUID[20]? Why doesn't this make sense? I don't follow. > > Nothing is invalid, I just think it's better and expresses the intent more > clearly if you can only assign between UUIDs of the same size. For example, > If the UUID class were templated on size, then there would not even be such > thing as a UUID[0] or a "universally invalid UUID". There would be an > "invalid 16-byte UUID" and an "invalid 20-byte UUID", and those would be > different things. > > >> >> As a future cleanup, I think this class should probably be a template such >> as UUID<N>, and then internally it can store a std::array<uint8_t, N>. And >> we can static_assert that N is of a known size if we desire. > > UUID values are objects contained as members inside of other objects. They > all default to start with no preconceived notion of what the UUID should be. > IMHO the UUID class is just fine and needs to be able to represent any UUID, > from empty uninitialized ones, and be able to be assigned and changed at will. > > > Is there ever a use case for changing the number of bytes in a UUID? If > you're working with 16-byte UUIDs, does it ever actually happen that now you > have a 20-byte UUID? Can you imagine a use case currently where an N-byte > UUID is being compared against an M-byte UUID in a real-world scenario? If > the answer is no, then it may as well be enforced by the compiler.
The ObjectFile class has a "UUID m_uuid;" member that any object file can fill in. Right now mach-o files have 16 byte UUIDs. ELF files can have 20 bytes UUIDs (build ID) or 4 byte UUIDs (debug info CRC if no build ID is around, and these are current represented as 20 byte UUIDs with just the first 4 bytes filled in. So no, we can't enforce this using the compiler. I don't see a need to change way from a byte buffer that has the max number of bytes needed for any currently supported UUID (20 right now).
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
