[-] timhh@programming.dev 1 points 2 weeks ago* (last edited 2 weeks ago)

What docs? A bool is one byte. Get over it. Find me one normal compiler/architecture in C, C++, Go, Rust, Zig, etc. where it is not. Go on.

[-] timhh@programming.dev 0 points 2 weeks ago

It is not. A bool in C, C++, Rust, Go, and every language that I know is 1 byte. Why are you arguing this basic very well known fact so much?

Just say "oh I was mistaken, TIL". It's not shameful.

[-] timhh@programming.dev 0 points 2 weeks ago

but calling malloc_usable_size(malloc(1)) is giving me 24, so it at least allocated 24 bytes for my 1, plus any tracking overhead

Indeed. Padding exists. A bool is still one byte.

it’ll get 3+ extra bytes added on the next fn call.

...of padding. Jesus. Are you going to claim that uint16_t is not 2 bytes because it is sometimes followed by padding?

[-] timhh@programming.dev 0 points 2 weeks ago

Wrong again. It depends on the CPU. They can absolutely read a single byte and they will do if you're reading from non-idempotent memory.

If you're reading from idempotent memory they won't read a byte or a word. They'll likely read a whole cache line (usually 64 bytes).

And if you read the ARM article you linked, it literally says so.

Where?

Thus any compiler worth their salt will align all byte variables to words for faster memory access.

No they won't because it isn't faster. The CPU will read the whole cache line that contains the byte.

RTFM

Well, I would but no manual says that because it's wrong!

[-] timhh@programming.dev 0 points 2 weeks ago

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.

[-] timhh@programming.dev 1 points 2 weeks ago

You said you can't read one byte. I showed that you can. Where's the confusion?

[-] timhh@programming.dev 1 points 2 weeks ago

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.

[-] timhh@programming.dev 1 points 2 weeks ago

The biggest problem is that each element doesn't have a unique memory address; iterators aren't just pointers.

[-] timhh@programming.dev 0 points 2 weeks ago

You can’t read one byte

lol what. You can absolutely read one byte: https://godbolt.org/z/TeTch8Yhd

On ARM it's ldrb (load register byte), and on RISC-V it's lb (load byte).

Every decent compiler will turn booleans into words.

No compiler I know of does this. I think you might be getting confused because they're loaded into registers which are machine-word sized. But in memory a bool is always one byte.

[-] timhh@programming.dev 0 points 2 weeks ago

You can't store data in parity bits... so it's irrelevant.

[-] timhh@programming.dev 2 points 2 weeks ago

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?

view more: ‹ prev next ›

timhh

joined 3 weeks ago