There are a few reasons you shouldn’t use this in proper programs. If you’re the sort of person that thinks hacky Bash scripts are acceptable then sure, use it there.

1. It isn’t cross-platform. Not available on Mac/Windows.
2. There are several types of UUID with different properties. This doesn’t let you choose which one to use.
3. To make programs deterministic (really useful for testing!) you want to be able to seed all their randomness with a specific seed so that it generates the same UUID each time you run it. (Obviously in normal use you would use a random seed.)

Yeah but please don’t actually use this. Use a proper UUID library that works cross-platform and lets you choose the UUID type and can be seeded etc.

but if you have a single bool in a stack frame it’s probably going to be more than a byte.

Nope. - if you can’t read RISC-V assembly, look at these lines

        sb      a5,-17(s0)
...
        sb      a5,-18(s0)
...
        sb      a5,-19(s0)
...

That is it storing the bools in single bytes. Also I only used RISC-V because I’m way more familiar with it than x86, but it will do the same thing.

on the heap definitely more than a byte

Nope, you can happily malloc(1) and store a bool in it, or malloc(4) and store 4 bools in it. A bool is 1 byte. Consider this a TIL moment.

things that store it as word size for alignment purposes

Nope. bools only need to be naturally aligned, so 1 byte.

If you do

struct SomeBools {
  bool a;
  bool b;
  bool c;
  bool d;
};

its 4 bytes.

It’s not just less memory though - it might also introduce spurious data dependencies, e.g. to store a bit you now need to also read the old value of the byte that it’s in.

I don’t think so. Apart from dynamically typed languages which need to store the type with the value, it’s always 1 byte, and that doesn’t depend on architecture (excluding ancient or exotic architectures) or optimisation flags.

Which language/architecture/flags would not store a bool in 1 byte?