Variant can never be None #459

New issue

Closed

opened 2020-02-25 01:17:44 -06:00 by Fleshgrinder · 1 comment

Fleshgrinder commented

2020-02-25 01:17:44 -06:00

(Migrated from github.com)

The variant currently returns an Optional and has a None branch, however, this branch is actually unreachable. As a reminder, here is what the RFC has to say about the variant:

   The following table lists the contents of the variant field, where
   the letter "x" indicates a "don't-care" value.

   Msb0  Msb1  Msb2  Description

    0     x     x    Reserved, NCS backward compatibility.
    1     0     x    The variant specified in this document.
    1     1     0    Reserved, Microsoft Corporation backward compatibility
    1     1     1    Reserved for future definition.

— RFC 4122: 4.1.1. Variant

What we can derive from this (and is correctly coded in the library) is:

Anything that start with 0 is NCS, regardless of what comes next.
Anything that start with 10 is RFC, regardless of what comes next.
110 is always MS, and
111 is always future.

There is no combination possible that would lead no variant being present, regardless of the contents of the UUID value.

I created a playground snippet to proof it, just in case the theory is not enough.

The Optional should be removed and either Variant.Future is returned in the last match arm or unreachable! is used. The doc of the function should be extended to explain this and warn users that they should only trust the variant if the UUID they are dealing with comes from a trusted source (this is actually true for any UUID introspection since it‘s just random data after all).

The [`variant`](https://github.com/uuid-rs/uuid/blob/9bb93b63c983a5df05df06eaef007d55fb3728bd/src/lib.rs#L261-L275) currently returns an `Optional` and has a `None` branch, however, this branch is actually unreachable. As a reminder, here is what the RFC has to say about the variant: ``` The following table lists the contents of the variant field, where the letter "x" indicates a "don't-care" value. Msb0 Msb1 Msb2 Description 0 x x Reserved, NCS backward compatibility. 1 0 x The variant specified in this document. 1 1 0 Reserved, Microsoft Corporation backward compatibility 1 1 1 Reserved for future definition. ``` — [RFC 4122: 4.1.1. Variant](https://tools.ietf.org/html/rfc4122#section-4.1.1) What we can derive from this (and is correctly coded in the library) is: 1. Anything that start with `0` is NCS, regardless of what comes next. 1. Anything that start with `10` is RFC, regardless of what comes next. 1. `110` is always MS, and 1. `111` is always future. There is no combination possible that would lead no variant being present, regardless of the contents of the UUID value. I created [a playground snippet](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ee0967154c7a8959c6648a580d4fcf65) to proof it, just in case the theory is not enough. ---- The `Optional` should be removed and either `Variant.Future` is returned in the last match arm or `unreachable!` is used. The doc of the function should be extended to explain this and warn users that they should only trust the variant if the UUID they are dealing with comes from a trusted source (this is actually true for any UUID introspection since it‘s just random data after all).

KodrAus commented

2021-10-30 16:48:48 -05:00

(Migrated from github.com)