uuid-rs/uuid

Generate and parse UUIDs.

uuid's Issues

serde trait `serde::Serialize` and `serde::Deserialize` not implemented

Hi,

I try to migrate my project from rustc_serialize to serde and I declared the serde feature for uuid in the Cargo.toml file but still get this error.

error[E0277]: the trait bound `uuid::Uuid: serde::Serialize` is not satisfied
   --> src/lib.rs:305:44
    |
305 | #[derive(Copy, Clone, Hash, PartialEq, Eq, Serialize, Deserialize)]
    |                                            ^^^^^^^^^ the trait `serde::Serialize` is not implemented for `uuid::Uuid`

error[E0277]: the trait bound `uuid::Uuid: serde::Deserialize` is not satisfied
   --> src/lib.rs:305:55
    |
305 | #[derive(Copy, Clone, Hash, PartialEq, Eq, Serialize, Deserialize)]
    |                                                       ^^^^^^^^^^^ the trait `serde::Deserialize` is not implemented for `uuid::Uuid`
    |
    = note: required by `serde::Deserialize::deserialize`

error[E0277]: the trait bound `uuid::Uuid: serde::Deserialize` is not satisfied
   --> src/lib.rs:305:66
    |
305 | #[derive(Copy, Clone, Hash, PartialEq, Eq, Serialize, Deserialize)]
    |                                                                  ^ the trait `serde::Deserialize` is not implemented for `uuid::Uuid`

Cargo.lock:

[[package]]
name = "serde"
version = "0.8.23"
source = "registry+https://github.com/rust-lang/crates.io-index"

[[package]]
name = "serde"
version = "0.9.3"
source = "registry+https://github.com/rust-lang/crates.io-index"

[[package]]
name = "serde_codegen_internals"
version = "0.12.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
 "syn 0.11.4 (registry+https://github.com/rust-lang/crates.io-index)",
]

[[package]]
name = "serde_derive"
version = "0.9.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
 "quote 0.3.12 (registry+https://github.com/rust-lang/crates.io-index)",
 "serde_codegen_internals 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "syn 0.11.4 (registry+https://github.com/rust-lang/crates.io-index)",
]

[[package]]
name = "serde_json"
version = "0.9.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
 "dtoa 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)",
 "itoa 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)",
 "num-traits 0.1.36 (registry+https://github.com/rust-lang/crates.io-index)",
 "serde 0.9.3 (registry+https://github.com/rust-lang/crates.io-index)",
]

[[package]]
name = "uuid"
version = "0.3.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
 "rand 0.3.15 (registry+https://github.com/rust-lang/crates.io-index)",
 "serde 0.8.23 (registry+https://github.com/rust-lang/crates.io-index)",
]

Code:

#[derive(Copy, Clone, Hash, PartialEq, Eq, Serialize, Deserialize)]
pub struct ClientId(Uuid);
impl ClientId {
    fn new() -> ClientId {
        ClientId(Uuid::new_v4())
    }
    fn as_bytes(&self) -> &[u8] {
        self.0.as_bytes()
    }
    fn from_bytes(bytes: &[u8]) -> Result<ClientId> {
        match Uuid::from_bytes(bytes) {
            Ok(uuid) => Ok(ClientId(uuid)),
            Err(_) => Err(Error::Raft(RaftError::InvalidClientId)),
        }
    }
}

Documentation not available anymore (404)

Hi,

I get a 404 when checking the doc: https://doc.rust-lang.org/uuid.

appveyor button missing

A button linking to the following link should be provided in README, as we now have appveyor builds

https://ci.appveyor.com/project/KodrAus/uuid

Introduce C interface

We should provide a C interface for the crate for anyone who wants to use uuid crate as an alternative to other implementations. If we decide on going ahead with this, it will need some serious discussion in order to make a good API.

Provide runConfigurations for IntelliJ

Description

Provide the various acceptable run configurations, based on the CI environments.

Other

Allows testing with various configurations locally to ensure everything works.

UUID Version 1 Implementation

Hi. I've just made experimental implementation of UUID Version 1, uuid_v1_rs, due to lack of implementation of uuid v1 in this crate.

I'd like to merge this experimental implementation into this crate. Could I work for this?

Document how to enable rustc-serializeable / serde serializable Uuids.

I just upgraded some code from using 0.1.x to 0.2.x and I'm having some compiler trouble now as I assumed it would remain serializable by the JSON serializer. Is there work I need to do on my end, or is this on the Uuid libary's end?

Here's the error rustc is spitting out:

src/data/sale.rs:22:2: 22:14 error: no method named `encode` found for type `uuid::Uuid` in the current scope
src/data/sale.rs:22     pub id: Uuid,

And a snippet:

    extern crate uuid;

    use self::uuid::Uuid;

    #[derive(RustcDecodable, RustcEncodable, Clone, Debug)]
    pub struct Thingamajig {
        /// Identifier for object lookup (eg database)
        pub id: Uuid,
        /// A title. This is for humans
        pub title: String,
    }

Split lib.rs into multiple files

Currently lib.rs consists of ~1500 LoC and includes nearly everything written in the file.

A better way would be to have internal mods and export important [and maybe all] -> needs debate on structure

some features not found in Cargo.toml

all features rustc-serialize serde v1 v3 v4 v5 use_std, but only v1 v3 v4 v5 use_std in the Cargo.toml, lack of rustc-serialize serde(i am new to rust-lang, maybe this is a stupid question).

UUID v4 generation

Random UUIDs are specified in RFC 4122 Section 4.4. There are six bits with a fixed value that either give the version number or are reserved for future use. The random UUIDs generated by this crate and labeled v4 are completely filled with random bytes and thus differ from the RFC. I am aware that it is possible to set the values with set_version and set_variant and get RFC conforming UUIDs. I think the crate should only generate RFC 4122 UUIDs so the version and variant field can be read. At least the new_v4 should be renamed to another name like new_random.

v1 UUIDs

Is there a desire to have such a thing in this crate?

They would mutually exclusive with the [nostd] directive, since time::get_time would be the preferred method for getting at least 60 bits of precision of time since 1582.

In addition, it would need to take a context in order to store a counter in case of clock collisions due to low resolution on a platform.

Also "Node ID" is a vague notion, usually the mac address, but I assume we'd just want to let someone pass in 16 bytes for that.

So an interface might be:

pub fn new_v1_context() -> UUidV1Context;  

pub fn new_v1(&UUidV1Context,  &[u8; 16]) -> Uuid; 

}

The context would be internally mutable, using, say, a local atomic uint counter.

Thoughts?

Is serde implementation going to be stable?

Hi!

Are you going to stick with hyphenated format for all time?

Possible to seed UUID v4 random number generator?

As in the title. That would be very useful for e.g. tests where determinisms highly desired.

impl Error for ParseError

Would it be possible to implement std::error::Error for uuid::ParseError? I'm trying to use

error_chain! {
    foreign_links {
        // ...
        uuid::ParseError, Uuid;
    }
}

in code I'm writing, but I think it's failing because uuid::ParseError doesn't implement std::error::Error:

error: no method named `cause` found for type `&uuid::ParseError` in the current scope
  --> src/errors.rs:23:1
   |
23 | error_chain! {
   | ^
   |
   = note: this error originates in a macro outside of the current crate

error[E0277]: the trait bound `uuid::ParseError: std::error::Error` is not satisfied
  --> src/errors.rs:23:1
   |
23 | error_chain! {
   | ^ trait `uuid::ParseError: std::error::Error` not satisfied
   |
   = note: required by `std::error::Error::description`
   = note: this error originates in a macro outside of the current crate

error: aborting due to 2 previous errors

Use cfg_if for a cleaner sourceset

This should help in reading the sources a bit easier, as it helps in reading attributes in a more logical sense.

Reference: #124

sha1 0.5

It would be very nice if you could update sha1 dependency to 0.5 before 0.6.

Require atleast two review approvals before merge

As per discussion on gitter, we would require atleast two approvals.

Github gives a greenlight on atleast one, which won't be good enough for us. Fortunately bors does have a configuration option that we can enable.

Related: https://bors.tech/documentation/

docs not found

https://doc.rust-lang.org/uuid/uuid/index.html leads to a 404

Implement Error trait

the trait std::error::Error is not implemented for uuid::ParseError

Release 0.6.1

Items left to do for 0.6.1 release:

• Update version numbers in:
  • lib.rs
  • Cargo.toml
• Push to crates.io
• Write release notes on:
  • Github Releases
  • users.rust-lang.org

the trait bound ** is not satisfied problems - conflict

Hello.

I just need to get UUID from Postgres and serialize with serde. My Cargo.toml:

[dependencies]
serde="1.0.2"
serde_derive="*"
bincode="*"

[dependencies.uuid]
version = "0.5.0"
features = ["serde"] //allows Serialize

[dependencies.postgres]
version = "*"
features = ["with-uuid"] //allows ToSQL

version=0.5.0 let me to download new version of UUID and Serialize works for UUID (0.4.0 not), but postgres-shared wants 0.4.0.

cargo tree

├── postgres v0.14.1
│   ├── bufstream v0.1.3
│   ├── fallible-iterator v0.1.3
│   ├── log v0.3.7 (*)
│   ├── postgres-protocol v0.2.2
│   │   ├── byteorder v1.0.0 (*)
│   │   ├── fallible-iterator v0.1.3 (*)
│   │   ├── md5 v0.3.4
│   │   └── memchr v1.0.1
│   │       └── libc v0.2.22 (*)
│   └── postgres-shared v0.2.1
│       ├── fallible-iterator v0.1.3 (*)
│       ├── hex v0.2.0
│       ├── phf v0.7.21
│       │   └── phf_shared v0.7.21
│       │       └── siphasher v0.2.2
│       ├── postgres-protocol v0.2.2 (*)
│       └── uuid v0.4.0 (*)
├── serde v1.0.2 (*)
├── serde_derive v1.0.2
│   ├── quote v0.3.15
│   ├── serde_derive_internals v0.15.0
│   │   ├── syn v0.11.11
│   │   │   ├── quote v0.3.15 (*)
│   │   │   ├── synom v0.11.3
│   │   │   │   └── unicode-xid v0.0.4
│   │   │   └── unicode-xid v0.0.4 (*)
│   │   └── synom v0.11.3 (*)
│   └── syn v0.11.11 (*)
└── uuid v0.5.0
    └── serde v1.0.2 (*)

So where are 2 versions of uuid and i get error

the trait bound `uuid::Uuid: postgres::types::FromSql` is not satisfied

• How rust will compile this? It think that where are 2 different separated structs UUID? How about shared methods and same memory?
• How to resolve this conflict? I edited Cargo.toml of postgres-shared in cargo cache and later cargo clean, but It uses 0.4.0 again.

Custom RNGs

According to the docs, it should be possible to use the rand::Rand trait's rand() method to generate a v4 UUID using a custom RNG:

If you'd like to use a custom generator, don't use this method: use the rand::Rand trait's rand() method instead.

However, as of addaecd, Uuid no longer implements rand::Rand even if v4 support is enabled. Is there some other mechanism to specify a custom RNG?

Tracker: Release 0.6

Items left to do for 0.6 release:

• Update version numbers in:
  • README.md
  • lib.rs
• Push to crates.io
• Write release notes on:
  • Github Releases
  • users.rust-lang.org

Implementation of Uuid version 2 missing?

Going through lib.rs, I didnt see the implementation for it, although the UuidVersion does have a variant for it.

add wip probot

This will prevent accident merge of WIP PRs

fix doc formatting to prevent warnings

Currently we get something along the lines of this when creating docs, this should be ideally not print

Index out of bounds panic in UUID parser

Hello,

I managed to cause an index out of bounds panic in the parse_str function with the following input:

assert_eq!(Uuid::parse_str("231231212212423424324323477343246663"), Err(InvalidLength(36)));

The problem here is that the parser_str function checks for the input length (32 or 36), but does not have any "hyphen verification" in the 36 case. Because of this, the 33rd digit will cause the panic:

index out of bounds: the len is 16 but the index is 16', src/lib.rs:489

let mut buffer = [0u8; 16];
//...
buffer[(digit / 2) as usize] = acc;
//      ^^^^^^^^^
//         16

I tried to implement a quick fix in two different ways, but both have drawbacks.
I can count the hyphens when the input length is 36, or I can just check for the digit index variable in every iteration of the parser loop.

Which would be more efficient / cleaner solution? What kind of ParseError should I return in this case?

Provide the prelude module

Description

Introduce the prelude module.

Feature Request

This should be considered a part of the refactor process. This will allow library users to have the same layout as the current root mod, but will allow us to move various pieces of code into separate modules without continuously breaking the users.

Other

#124

Tracker: Release 0.6-beta

Items left to do for 0.6-beta release:

• Update version numbers in:
  • README.md
  • lib.rs
• Push to crates.io
• Write release notes on:
  • Github Releases
  • users.rust-lang.org

Same steps have to be repeated for stable 0.6 release

Update crates.io version

Crates.io version is not up to date and doesn't compile on rustc master.

V1 Generator Should not Always Increment Sequence Counter

The V1 generation code (new_v1) rightly state the following in the documentation:

This function is only guaranteed to produce unique values if the following conditions hold:

1. The NodeID is unique for this process.
2. The Context is shared across all threads which are generating V1 UUIDs
3. The supplied seconds+nsecs values are monotonically increasing.

Items 1 and 2 can be reasonably guaranteed in a system but the 3rd item is nearly impossible to guarantee in practice as the value needs to be monotonically increasing across the entire life of the system (not just a given boot).

Both the RFC for UUID (RFC4122) and the DCE documentation provide similar guidelines on when the sequence should be modified.

I propose the following change (which I can create a PR for):

1. Make the UuidV1Context a trait so that the implementation can be plugged as needed. This is important if one wanted to, for instance, ensure that changes to the time/sequence were persisted.
2. Make the UuidV1Context responsible for storing the most recent time value (in resolution of 100nsecs).
3. Add a method for getting an appropriate sequence number from a context given the current generation time. As per the RFC recommendation, this sequence number would not change if the time was after the last time seen. If the time was the same or prior to the last time seen, then the sequence number would be incremented.

Per RFC4122:

4.1.5. Clock Sequence

For UUID version 1, the clock sequence is used to help avoid
duplicates that could arise when the clock is set backwards in time
or if the node ID changes.

If the clock is set backwards, or might have been set backwards
(e.g., while the system was powered off), and the UUID generator can
not be sure that no UUIDs were generated with timestamps larger than
the value to which the clock was set, then the clock sequence has to
be changed. If the previous value of the clock sequence is known, it
can just be incremented; otherwise it should be set to a random or
high-quality pseudo-random value.

UUID parsing shouldn't need any allocation

The UUID parsing routine right now uses at least three allocations: The vector of groups, the vector of group lengths, and the concatenated string of all hex digits. It should be easy to rewrite this to avoid any allocation whatsoever.

Add a Nil variant in UuidVersion enum

0x0 version number is a valid value for UuidVersion, as per spec. This would make it required for users to explicitly check for the nil UUID.

Add clippy lint tests

ideally should run in the same build session as the one that tests for rustfmt

0.1.18 Runtime Incompatibility

I suggest creating an explicit unit test for string formatting of the UUID's Debug and Display impl. 0.1.17 used to_simple_string() to format Display, while 0.1.18 uses to_hyphenated_string(), which is an incompatible update under a compatible semver bump (0.1.17 -> 0.1.18). The version should have been 0.2.0 or Display should have been left as is for 0.1.18.

Thanks.

Drop rustc-serialize dependency

It has been deprecated: announcement.

Add a version of `Uuid::from_fields` that can't fail

Uuid::from_fields takes an &[u8] for d4, so it will return an error if d4 is not 8 bytes in length. Every time I've used this method I've had an 8 byte array to hand, so it seems silly to have to call unwrap on the result. It would be nice if there was a version of this like fn from_fields(d1: u32, d2: u16, d3: u16, d4: &[u8; 8]) -> Uuid.

I realize that working with arrays is sort of a pain in Rust for several reasons. Once the const generics RFC gets implemented it should make some things simpler, like making it possible to have a method on slices that returns an array reference of a certain size.

Generate v3 UUIDs

I'm trying to get a v3 (md5 name based) uuid. I didn't found a something to do that. Could you add a way to do that or do I miss something?

macOS builds missing

This is a debatable topic, as it will add to the build times, but on the other hand should provide testing on Apple platform

New release?

I'd like to push some crates to crates.io, but I need the Error trait from #44 in order to be able to do so. Could a new release with it included be tagged? Thanks.

Rename `use_std` feature to `std` (C-FEATURE)

As per guidelines.

Tracker: Release 1.0

This is a list of things we need to do before we can release a stable version of uuid.

• #106
• #90
• Shift into rust-lang org
  • RFC (as per https://github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md)
• set up for bors?
• Find a new home for uuid
• #191
• Public dependencies:
  • [ ] Rename serde to serde1
  • [ ] Rename slog to slog2
  • Shift winapi into an external library (uuid-winapi)
  • Remove stdweb and rename wasm-bindgen to js
• 1.0.0!

Release 0.2.0?

As your docs say, one can depend on this crate by placing uuid = "0.2" in Cargo.toml, but the latest available version on crates.io is 0.1.18 - could you please do another release? I need this for serde support (It seems Serialize implementation for the Uuid type does not work with serde 0.7.0 in my crate and 0.6.something in uuid...)

Add issue, pr templates

Templates not template, as github recently added support for multiple templates.

Rustdoc documentation

Please make the rustdoc documentation available online and be kept up to date. (In this case, I’m looking for what the to_simple_str method has become.)

(This applies to all crates moving out of the rustc distribution, since http://doc.rust-lang.org will get out of date.)

Use appropriate RNG for version 4 generation

Version 4 identifiers are generally expected to be globally random, unique and collision free. To ensure this, a cryptographically secure random number generator should be used. Most if not all implementations (for example, libuuid, Java and Python) do this.

Secure defaults are important. The current code uses thread_rng, which is not suitable for this purpose according to the rand documentation.

Make `Uuid` implement `Copy`

This will improve ergonomics a little, thoughts?

Use `std` by default

Most users of uuid will be std users, anyone who is working on architectures that don't have support for std can disable the feature.

Steps needed:

• Introduce the default key under [features] that has ["std"] in Cargo.toml.
• Change CI environments so the change is reflected. Not needed
• Update documentation to reflect the changes.
• Edit rust files to reflect the change.

Repeatable UUIDs for debugging

It’s really hard to debug a program using UUIDs when they change on each run. I would really like a debug option, perhaps one that takes a value as an argument, that returns the same sequence of UUIDs on every run that supplies that value. I’ve used random number routines with that option, and it really helps when debugging.

Of course, the danger is forgetting to turn off the feature for production (something I’ve done), so you should probably provide some notification that it’s in use. A prefix on the generated UUIDs, something like DEBUG-xxxxxx, should do the trick.

rearrange str and string usage in the API.

libuuid mixes up string and str in method signatures, specifically the name of the method itself.

Proposed changes:

fn to_simple_str(&self) -> String => fn to_simple_string(&self) -> String
fn to_hyphenated_str(&self) -> String => fn to_hyphenated_string(&self) -> String
fn to_urn_str(&self) -> String => fn to_urn_string(&self) -> String
fn parse_string(us: &str) -> Result<Uuid, ParseError> => fn parse_str(us: &str) -> Result<Uuid, ParseError>

originally at rust-lang/rust#15731

Ill make a PR soon :)