UUIDGEN(2)

πŸ“¦ version 15.1, in freebsd 14.5, freebsd 15.1

✨ UUIDGEN(2) ✨

okay bestie so this is a System Calls Manual page, and honestly it's a whole vibe β€” it's all about uuidgen πŸ’…


🌸 NAME 🌸

uuidgen β€” generate universally unique identifiers πŸ¦‹

πŸ’– LIBRARY πŸ’–

Standard C Library (libc, -lc) β€” yep, she's built in, no extra downloads needed, we love a low-maintenance icon ✨

πŸŽ€ SYNOPSIS πŸŽ€

#include <sys/uuid.h>

int
uuidgen(struct uuid *store, int count);

πŸ‘‘ DESCRIPTION πŸ‘‘

so basically, the uuidgen() system call generates count universally unique identifiers (UUIDs for short, iykyk) and writes them into the buffer that store points at 🫢. These identifiers are generated according to the syntax and semantics of the DCE version 1 variant of universally unique identifiers. There's a more in-depth description of the identifiers down below, don't worry, I got you πŸ’œ

When there's no IEEE 802 address available for the node field, a random multicast address is generated for each invocation of the system call. And because of how time-based UUIDs are generated, this also forces a new random clock sequence β€” which highkey increases the likelihood that the identifier ends up unique πŸ”₯. slay.

When you're generating multiple identifiers, the uuidgen() system call generates a set that is dense β€” meaning there's no identifier larger than the smallest identifier in the set and smaller than the largest identifier in the set that isn't already in the set. no gaps, no stragglers, the whole squad is accounted for, periodt πŸŽ€

Universally unique identifiers (also known as globally unique identifiers, AKA GUIDs) have a binary representation of 128 bits. The grouping and meaning of those bits is described by the following structure and the field breakdown right after it πŸ‘‡

struct uuid {
        uint32_t        time_low;
        uint16_t        time_mid;
        uint16_t        time_hi_and_version;
        uint8_t         clock_seq_hi_and_reserved;
        uint8_t         clock_seq_low;
        uint8_t         node[_UUID_NODE_LEN];
};
  • time_low β€” the least significant 32 bits of a 60-bit timestamp. This field is stored in the native byte-order πŸ’«
  • time_mid β€” the least significant 16 bits of the most significant 28 bits of the 60-bit timestamp. Also stored in the native byte-order ✨
  • time_hi_and_version β€” the most significant 12 bits of the 60-bit timestamp multiplexed with a 4-bit version number. The version number lives in the most significant 4 bits of this 16-bit field. Stored in the native byte-order 🌈
  • clock_seq_hi_and_reserved β€” the most significant 6 bits of a 14-bit sequence number multiplexed with a 2-bit variant value. Quick note: the width of the variant value is determined by the variant itself 😌. Identifiers generated by the uuidgen() system call have variant value 10b. The variant value is stored in the most significant bits of the field πŸ’…
  • clock_seq_low β€” the least significant 8 bits of a 14-bit sequence number πŸ“
  • node β€” the 6-byte IEEE 802 (MAC) address of one of the interfaces of the node. If no such interface exists, a random multi-cast address is used instead 🧚
⚠️ ok important: the binary representation is sensitive to byte ordering. Any multi-byte field is to be stored in the local or native byte-order, and identifiers must be converted when transmitted to hosts that don't agree on the byte-order. The spec does not document what this means in concrete terms tho, and that's otherwise beyond the scope of this system call πŸ™ˆ

⭐ RETURN VALUES ⭐

Upon successful completion, the value 0 is returned πŸŽ‰ otherwise the value -1 is returned and the global variable errno is set to indicate the error πŸ’€

πŸ’€ ERRORS πŸ’€

The uuidgen() system call can fail with:

  • [EFAULT] β€” the buffer pointed to by store could not be written to for any or all identifiers 😭
  • [EINVAL] β€” the count argument is less than 1 or larger than the hard upper limit of 2048. yes there's a hard cap bestie, respect the hard cap 🚫

πŸ¦‹ SEE ALSO πŸ¦‹

uuidgen(1), uuid(3)

🌟 STANDARDS 🌟

The identifiers are represented and generated in conformance with the DCE 1.1 RPC specification. The uuidgen() system call itself is not part of the specification β€” she's doing her own thing πŸ’…βœ¨

πŸ’œ HISTORY πŸ’œ

The uuidgen() system call first appeared in FreeBSD 5.0 πŸ‘‘


and that's the whole page, bestie 🫢 this one's a Debian production, dated May 26, 2002 β€” vintage but still iconic, no cap πŸŽ€πŸ’–βœ¨

πŸ“¦ where this page comes from