[Lldb-commits] [PATCH] D40537: Simplify UUID::IsValid()

[Zachary Turner via lldb-commits]

Also worth pointing out that when you write things this way, this UUID<n>
class can be part of a larger structure that matches the record layout of a
header or section in a binary file, and then you can just memcpy over the
class and your'e good to go.  For example you could have

```
struct MachOHeader {
   ...
   ...
   UUID<16> uuid;
   ...
};

MachOHeader H;
::memcpy(&H, File, sizeof(H));
File += sizeof(H);
```

and you could do the same for some ELF structure.

```
struct ElfHeader {
   ...
   ...
  union {
    UUID<20> BuildId;
    UUID<4> DebugCrc;
  }
   ...
};

ElfHeader H;
::memcpy(&H, File, sizeof(H));
File += sizeof(H);
```

And everything just works.

On Tue, Nov 28, 2017 at 11:36 AM Zachary Turner <zturner at google.com> wrote:

> Eh, that actually just makes me think the compiler *can* check it.  For
> example, right now you can have mach-o files with 20 byte UUIDs.  But just
> in the code, not in practice.  You could have a bug in your code that
> accidentally wrote the wrong number of bytes from a dynamic buffer.
>
> You could enforce this at the compiler level by saying:
>
> class ObjectFileMachO {
>   UUID<16> uuid;
> };
>
> Not only is this more correct, but it is less error prone and is also nice
> documentation to the reader who may be just learning about MachO that this
> UUID is always 16 bytes.
>
> For the case of ELF, it sounds like you either have a 20 byte UUID or a 4
> byte UUID, but never both, and never any other size.  That makes me think
> of:
>
> class ObjectFileELF {
>   union {
>     UUID<20> BuildId;
>     UUID<4> DebugCrc;
>   }
> };
>
> And now the person reading this code can immediately tell that there will
> either be one or the other, and depending on which one it is, he/she
> already knows something about it, like how many bytes it is and what it
> represents.
>
> To me this is much more clear than:
>
> class ObjectFileELF {
>   // This might not actually be a build id, and it could be a variable
> size, and you also have to be careful
>   // not to put some strange number of bytes in it that we don't
> recognize, but it's up to the user
>   // to know under what circumstances it should be a certain number of
> bytes, and you should also always
>   // be careful ensure that there's no buffer overruns since you'll be
> working with dynamically sized buffers
>   // and the compiler can't warn you when you're doing something wrong.
>   UUID BuildIdOrDebugCrc;
> };
>
> On Tue, Nov 28, 2017 at 11:06 AM Greg Clayton <clayborg at gmail.com> wrote:
>
>>
>> On Nov 28, 2017, at 10:24 AM, Zachary Turner <zturner at google.com> wrote:
>>
>>
>>
>> On Tue, Nov 28, 2017 at 10:18 AM Greg Clayton <clayborg at gmail.com> wrote:
>>
>>> On Nov 27, 2017, at 10:11 PM, Zachary Turner <zturner at 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).
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20171128/a46c7544/attachment-0001.html>