ghostty-org
core: add a UUID to every core surface
- Adds a 128bit UUID to every core surface.
- Expose that UUID as an environment variable.
- Add a function to the core app to search for surfaces by UUID.
One downside to an UUID is that you can't fit it inside a glib.Variant by itself (the type system only supports 64-bit integers at most), which means that when you want to pass the surface ID through our GTK actions, you either have to stuff it inside a string (ew, bad) or split it up into two u64s. Neither option sounds enticing, really...
Plus: u128s are also ill-defined at best in C land (just search "__int128" and the horrors therein), so every time you want to refer to a surface via libghostty you have to specify two u64s (or even worse, a string). Why not just use one single u64 in this case?
Yeah we may be able to get away with an incrementing u64. Surface creation can grab a lock to increment and you’d have to have an unfathomable amount of surfaces to ever overflow.
I’ve been meaning to look at that as an option.
Yeah we may be able to get away with an incrementing u64. Surface creation can grab a lock to increment and you’d have to have an unfathomable amount of surfaces to ever overflow.
Incrementing a u64 would def be my least preferred option. So many network protocols have had security issues due to easily predictable identifiers that I just automatically reject that as an option. Plus the need for a mutex.
If we aren't going for "real" UUIDs then std.crypto.random.int(u64) is the best way to go IMHO.
Yeah sorry saying incrementing was definitely wrong. I mean something closer to Snowflake.
If UUIDs are overkill because of their size, Snowflake IDs are overkill because of their complexity. Ghostty's not really a distributed system so all of that work constructing that ID is kinda pointless.
It’s roughly the same complexity as a UUID, some bits for time, some bits incremented, some bits random. Just 64 instead of 128 bits.