News for hackers. Stuff that matters.
Re:Comp.lang.c Frequently Asked Questions by addaon on Sunday September 12, 2021 @09:33PM (#28506918)
Either is valid, but int_fast8_t is more meaningful, in my mind. Using an int_fast8_t encourages the compiler to use the fastest representation, except when explicitly bit-packed. When the value is pulled into a register it's probably not going to matter (unless the compiler is doing something quite silly with regards to handling unsigned overflow for a uint*), but it means that spilling it to the stack, etc, will prefer word-sized operations (which may or may not be preferred, but is my default). Meanwhile, the bit packing is fully specifying the representation when the struct containing the value is written to memory, so there's no distinction between _fast and _least here.
Re:Comp.lang.c Frequently Asked Questions by jbboehr on Tuesday September 14, 2021 @04:43AM (#28521948)
> And of course we have bit packing when we need to pack more efficiently than reasonable; bit-packing with *int_fast8_t* allows you to represent "I need this to take exactly 8 bits of memory, whatever it costs compute-wise, because I'm basically filling memory with these."

AFAICT, "int_fast8_t" is generally typedef to "int", and "int_least8_t" is generally typedef to "char", which conflicts with "I need this to take exactly 8 bits of memory, whatever it costs compute-wise, because I'm basically filling memory with these."

Re:Comp.lang.c Frequently Asked Questions by addaon on Tuesday September 14, 2021 @05:18PM (#28531418)
Right. The context here is when combined with bit-packing, i.e. `int_fast8_t : 8` vs `int_least8_t : 8` in a struct or similar.