Would be great to see the author's treatment of memory allocation and lifecycle for complex data types.
My personal C coding style as of late 2023
101–110 of 466 posts
Re: My personal C coding style as of late 2023
#102Earlier 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.
Opinionated? Was there something else you wanted u8 to mean?
Re: My personal C coding style as of late 2023
#103Earlier quoted context omitted.
Yikes. I did have to go down a little rabbit hole to understand the semantics of that builtin (I don’t normally write C if that wasn’t immediately obvious from the question) but that seems like a really questionable interpretation of “this should never happen”. I would expect the equivalent of a fault being triggered and termination of the program, but I guess this is what the legacy of intentionally obtuse undefined…
The builtin itself is fine. It works exactly as it's intended. It says "I've double and tripple checked this. Trust me compiler. Just go fast". But you should not use it to construct an assert.
this is a true unconditional assert, e.g. "I assert that this condition is true". Problem is that's too much power to throw at most use cases.
Re: My personal C coding style as of late 2023
#104Earlier quoted context omitted.
Yikes. I did have to go down a little rabbit hole to understand the semantics of that builtin (I don’t normally write C if that wasn’t immediately obvious from the question) but that seems like a really questionable interpretation of “this should never happen”. I would expect the equivalent of a fault being triggered and termination of the program, but I guess this is what the legacy of intentionally obtuse undefined…
The builtin itself is fine. It works exactly as it's intended. It says "I've double and tripple checked this. Trust me compiler. Just go fast". But you should not use it to construct an assert.
Eh. I absolutely get what you're saying. And this is for sure flying very close to the knife's edge. But if your assertion checks don't run in release mode, and due to some bug, those invariants don't hold, well, your program is already going to exhibit undefined behaviour. Why not let the compiler know about the undefined behaviour so it can optimize better?
The nice thing about this approach is that the assertion provides value both in debug and release mode. In debug mode, it checks your invariants. And in release mode, it makes your program smaller and faster.
Personally I quite like rust's choice to have a pair of assert functions: assert!() and debug_assert!(). The standard assert function still does its check in both debug and release mode. And honestly thats a fine default these days. Sure, it makes the binary slightly bigger and the program slightly slower, but on modern computers it usually doesn't matter. And when it does matter (like your assertion check is expensive), we have debug_assert instead.
Re: My personal C coding style as of late 2023
#105I wish I could work with C again
C is wonderful so if you an find a project at work with a lot of C code then it'll remain forever. All these other fad languages will die before C ever does.
I'm hopeful for Zig as a modern replacement for C. It feels modern like rust, but still with C's lightness.
Re: My personal C coding style as of late 2023
#106Earlier quoted context omitted.
> I might just be a grumpy old dev [...] Everyone knows what a uint32_t is when they see it. You might not be old enough then :-P many codebases typedef their own int types. See glib (gint, gshort, gint32, etc), SDL (Sint32, Uint32, etc) off the top of my head and there are many that define types like "int32" or "i32" like the linked article.
I cut my teeth on DWORD, PHALF_PTR, and friends, so my issue is not so much “don’t know how to grok this” as it is “we finally have sane, universal type names and you’re throwing them away.” Sure, the _t suffix may be an eyesore but I’ll take size_t over “size” any day.
I like Rust's approach of "isize", as in "size" is in the place of the bit width. "size" sounds stupid.
Re: My personal C coding style as of late 2023
#107> #define sizeof(x) (size)sizeof(x) I'm guessing this is lacking an outer pair of parentheses (i.e. it's not `((size)sizeof(x))`) on the grounds that they're unnecessary. In terms of operator precedence, casting binds tightly, so if you write e.g. `sizeof(x) * 3`, it expands to `(size)sizeof(x) * 3`, which is equivalent to `((size)sizeof(x)) * 3`: the cast happens before the multiplication. Indeed, casting binds more…
(self-reply) One more thing. > I could use _Bool, but I’d rather stick to a natural word size and stay away from its weird semantics. This is even more subjective, but personally I like _Bool's semantics. They mean that if an expression works in an `if` statement: if (flags & FLAG_ALLOCATED) then you can extract that same expression into a boolean variable: _Bool need_free = flags & FLAG_ALLOCATED; The issue is that…
I always just use !! for this case.
Re: My personal C coding style as of late 2023
#108Earlier quoted context omitted.
Well ... Name a language is which you categorically cannot "shoot yourself in the foot"!
The issue is that it's a spectrum: how easily you can shoot yourself in the foot, especially on accident, without awareness of the risks. And perhaps what the consequences are when you do. Risk and consequence. C is high risk and also high consequence. In higher level languages, you can't shoot yourself in the foot nearly as easily in such a way as to trivially create a correctness problem and security vulnerability…
And even in Rust, the unsafe code guidelines and UB are extremely hotly debated and well-defined whenever possible.
Re: My personal C coding style as of late 2023
#109Earlier quoted context omitted.
10 years ago when ATmegas were still around and your 32 bit variable was generating 3 instructions for addition I would say „right on“ but now everything is a 32 bit Cortex-M and please stop polluting your code with this nonsense
Please understand, I am still in a position where I am writing new code for a platform which only has one compiler, a proprietary fork of GCC from nearly 20 years ago. I assume other C programmers might have similar situations.
> a proprietary fork of GCC
A what now?
Re: My personal C coding style as of late 2023
#110A lot of this makes sense to me. I’ve started writing a bare metal OS for Arm64. It’s very early but I’ve done some similar things. I’m using pascal strings, I’ve also renamed the types (though I’m using “int8” style, not “i8”). I quickly decided that I never intend to port real software to it, so I really don’t have to conform to standard C library functions or conventions. That’s given me more freedom to play aroun…
> I never intend to port real software to it, so I really don’t have to conform to standard C library functions or conventions.
So you're just building it as just a hobby, won’t be big and professional like gnu?