Live data from Hacker News

My personal C coding style as of late 2023

nullprogram.com

11–20 of 466 posts

Re: My personal C coding style as of late 2023

#11

Earlier quoted context omitted.

What's wrong with it?

Well, from a team perspective, it's extremely opinionated and hostile to newcomers and messes with core language features at the expense of readability. If it's your personal codebase then do whatever, obviously.

> extremely opinionated

I have not seen a single codebase that widely uses uint8_t and does not typedef it to u8. It is the exact opposite of "extremely opinionated".

Re: My personal C coding style as of late 2023

#13

Earlier quoted context omitted.

What's wrong with it?

Well, from a team perspective, it's extremely opinionated and hostile to newcomers and messes with core language features at the expense of readability. If it's your personal codebase then do whatever, obviously.

It doesn't mess with a core language feature to alias 'u8' to 'uint8_t'. It's a reasonable use for the name and one used in other languages (e.g., Rust). There's nothing in the C standard that defines or uses the 'u8' name.

Re: My personal C coding style as of late 2023

#14
Really lovely. A lot here reminds me of design in Odin lang. Short integral types, no const, composite returns over out params. Big fan of the approach of designing for a single translation unit and exploiting the optimisations that provides from RVO etc.

Re: My personal C coding style as of late 2023

#16

> To beginners it might seem like “wasting memory” by using a 32-bit boolean Maybe I'm a beginner then. He lists a few cases where it's not worse than sticking to 8-bit bools, but no cases where it's actually an improvement. It still wastes memory sometimes, e.g. if you have adjacent booleans in a struct, or boolean variables in a function that spill out of registers onto the stack. Sure it's only a few bytes here an…

Computer architecture is optimized for 32+ bit aligned access to most things. The gain is (usually, but not always!) performance.

Re: My personal C coding style as of late 2023

#18

> To beginners it might seem like “wasting memory” by using a 32-bit boolean Maybe I'm a beginner then. He lists a few cases where it's not worse than sticking to 8-bit bools, but no cases where it's actually an improvement. It still wastes memory sometimes, e.g. if you have adjacent booleans in a struct, or boolean variables in a function that spill out of registers onto the stack. Sure it's only a few bytes here an…

What's an example of a function where a boolean variable spills to the stack and the 3 bytes are important?

Re: My personal C coding style as of late 2023

#19

> To beginners it might seem like “wasting memory” by using a 32-bit boolean Maybe I'm a beginner then. He lists a few cases where it's not worse than sticking to 8-bit bools, but no cases where it's actually an improvement. It still wastes memory sometimes, e.g. if you have adjacent booleans in a struct, or boolean variables in a function that spill out of registers onto the stack. Sure it's only a few bytes here an…

And to add to that, if you use an actual bool type, sanitizers will warn you if they are ever any value other than false (0) or true (1).

Re: My personal C coding style as of late 2023

#20
post #17

> #define sizeof(x) (size)sizeof(x) Technically, it's illegal to #define over a language keyword.

really? then how do you #define things like types like `int` and `char`?

For example, it would be illegal to do the following:

> #define int long

Because you're replacing the int keyword with something else.

The standard says:

> 17.6.4.3.1 [macro.names] paragraph 2: A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 3, or to the attribute-tokens described in 7.6.

Post reply on HN