My personal C coding style as of late 2023 • Hacker News Board

Re: My personal C coding style as of late 2023

#111

Post by kazinator » Mon, Oct 09, 2023, 3:47 AM UTC

> #define sizeof(x) (size)sizeof(x)

That breaks any macro that uses sizeof in its expansion, and subtly changes any code snippet you might bring into the code that uses sizeof, even if those macro are defined first.

Speaking of which, if you define a macro for a C keyword before including any standard header, the behavior is undefined.

It's an unparenthesized unary expression, which has a lower precedence than postfix. sizeof(x)[ptr] will turn into (size)sizeof(x)[ptr] which parses as (size) ( sizeof(x)[ptr] ).

Re: My personal C coding style as of late 2023

#112

Post by __MatrixMan__ » Mon, Oct 09, 2023, 3:49 AM UTC

jpcfl wrote: post #78

Parameters and functions No const. Please don't. `const` is incredibly valuable, not only to the reader, but to the compiler. Take for example: int Foo_bar(Foo const* self); Just looking at this signature, I know that calling `bar()` will not modify the state of the object. This is incredibly valuable information to the reader. Furthermore, if I want to create a `Foo` constant, I can only call this function if it is…

Sorry for going off topic, but something fun I've learned lately is that in Nim (which compiles to C) changing:

let x = foo()

... to ...

const x = foo()

...runs foo at compile time to get the value. I dunno I just thought it was neat.

Re: My personal C coding style as of late 2023

#113

Post by lsh123 » Mon, Oct 09, 2023, 3:50 AM UTC

I wrote and still maintain an open source C project for 20+ years. Once a year I get a new guy coming in and telling me I am doing it wrong: you should typedef all data types, you should stop using const, and so on. It stopped being funny after the first couple times.

Re: My personal C coding style as of late 2023

#114

Post by CapsAdmin » Mon, Oct 09, 2023, 3:59 AM UTC

kstrauser wrote: post #109

xvedejas wrote: post #88

Earlier quoted context omitted.

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?

I think it's not a GPL violation if you keep the fork non-public.

Though I'm entirely sure not when something is considered private or public. You can obviously make changes to a GPL repo, compile it and run the executable yourself and just never release the source code.

But what happens when you start sharing the executable with your friends, or confine it to a company?

"I made this GCC fork with some awesome features. You can contact me at joe@gmail.com if you're intere$ted ;)"

Re: My personal C coding style as of late 2023

#115

Post by billforsternz » Mon, Oct 09, 2023, 4:06 AM UTC

comex wrote: post #57

comex wrote: post #33

> #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…

This is all very good and very, ahem, true. But (and it's a big butt);

if (need_free == true)

Is such a horrible code smell to me. You have a perfectly good boolean. Why compare it to a second boolean to get a third boolean?

if (need_free)

or

if (!need_free)

for the opposite case is so much better.

I will admit that in my world this leaves

if (need_free == some_other_bool)

as something I don't have a particularly comfortable way of doing safely.

Re: My personal C coding style as of late 2023

#116

Post by keyle » Mon, Oct 09, 2023, 4:13 AM UTC

WalterBright wrote: post #54

Interesting how my experience has led me in a different direction: https://dlang.org/blog/2023/10/02/crafting-self-evident-code... (The article is crafted around D, but the principles apply to C as well.)

Fun read.

    What happened to the conditional expressions? Move them to the interiors of doX() and doZ().

That was an interesting point. Not sure that it's always valid but I guess it depends where you want the abstraction to lay, and how it affects the mental construct around the code.

e.g.

    deleteRecords();

is not better than

    if let x = deadRecords()
       deleteRecords(x);

Sure, it looks messier but there is value is showing upfront that you're pruning and not wiping.

If the author wisely renames his function e.g. pruneDeadProjects(), yes. But merely moving the the condition within the function can be dangerous for context and be a leaky abstraction.

Re: My personal C coding style as of late 2023

#117

Post by Izkata » Mon, Oct 09, 2023, 4:16 AM UTC

f33d5173 wrote: post #70

oh_sigh wrote: post #40

Earlier quoted context omitted.

Also, `#define countof(a) (sizeof(a) / sizeof(*(a)))` is unsafe since the arg is evaluated twice.

The arg is expanded twice but evaluated zero times, since sizeof gives the size of its argument type without executing anything.

countof(foo()) looks like foo() is only called once, but would actually be called twice. That's what GP is talking about, it's evaluated twice after the expansion when the code is actually running, not during the expansion.

Re: My personal C coding style as of late 2023

#118

Post by jes5199 » Mon, Oct 09, 2023, 4:17 AM UTC

slimsag wrote: post #62

drpixie wrote: post #51

While there are a few disagreeable points, I like the article. I've always felt that C is unfairly maligned. Yes, it's very low level, it's meant to be. Yes, it lets you shoot yourself in the foot, but what language doesn't? Most of the problems with C are really issues with the standard library, the Unix (now Posix) interfaces, and the string type. None of these are actually part of C, but are part of how C is norma…

It's not unfairly maligned, it's just that everyone remembers their college/university 'learning experience' which made no distinction between C/C++, they were told to use the Borland compiler, and when trying to learn printing "hello world" they only got a `segmentation fault` error instead of a stack trace. When they asked why it's so hard, they were told C/C++ is hard - so they dropped the class. Then they picked…

do compilers like gcc support stack traces now?

Re: My personal C coding style as of late 2023

#119

Post by laserbeam » Mon, Oct 09, 2023, 4:21 AM UTC

lsh123 wrote: post #113

I wrote and still maintain an open source C project for 20+ years. Once a year I get a new guy coming in and telling me I am doing it wrong: you should typedef all data types, you should stop using const, and so on. It stopped being funny after the first couple times.

I'm getting an "I don't use const, and here's my view on it" vibe from the author much more than "you shouldn't use const". I'm really not getting any demand that you change your coding style, just someone reflecting on their work and explaining it to others. And... Whether I agree with their choices or not, I find that very cool and informative.

Re: My personal C coding style as of late 2023

#120

Post by thetic » Mon, Oct 09, 2023, 4:22 AM UTC

LegionMammal978 wrote: post #77

thetic wrote: post #67

Earlier quoted context omitted.

The legal cases in which he needs to cast away const could be avoided if the arguments to called functions were appropriately qualified.

He never said he needs to cast away const to do what he is attempting to do, he just said that he wants to cast away const to reduce clutter, even though the program would have the same semantics as if he kept the const.

If only there were a way to indicate the function argument isn't mutated.

My spidey senses tingle whenever I see const-ness cast away because it almost always means something is wrong. Either a function is missing a qualifier on an argument, or something very unsafe is happening. Why force callers to cast away const-ness in hopes that everything will be fine when you can just write the correct function signature.