My personal C coding style as of late 2023

There's a really good chance you will either have to promote or cast away the const, which I hate.

I tend to agree regarding not using const. It's been a while, so I don't have an example off the top of my head, but it's incredibly easy to break the const mechanism and have to deal with these annoying flaws.

I've just seen this go really bad with any kind of code that has a split responsibility between teams. Eventually you will have to pass to a non-const interface, that you aren't supposed to change.

So perhaps it makes sense if you have control from the top down and can ensure that the constness is maintained, or completely not, if it ends up non-const (then you could also try to move the interface to const, if it truly is)...

... I also suspect in many projects you'd just have to come to the conclusion that nothing can be const'd, because it ends up non-const anyway. Thus leading to the conclusion "just don't use const".

P.S. I'm a bad boy that didn't read TA yet. This is just based on my past experience where we didn't really have the authority to change stuff in the stack... often times there was eg an MCU interface at the end that was non-const... guess we could contact the silica manufacturer... sure they'll get right on that.

This introduces flaws in the type system. I wish I had a better breakdown on the impact of these concerns, but I'd rather not worry at all.

Anyway, if you don't use const, this goes away. Bear in mind the minor amount of "safety" it provides, because you can just ignore it later, as you arguably tend to be doing anyway when you pass a const to non-const or visa versa.

Inevitably, outside of really small insular project (and often times even then), there's something down the line that winds up being non-const that you don't want to change.

C developers of this mindset tend to just come to the conclusion that you will immediately break the type system, just give up on the whole game.

Edit adding at least on example:

Example: You define as const and remove the const later. If anything writes to the non-const, this is undefined behavior

Example: I believe the above is actually true for const promotion if you modify the non-const version... I think this is only after the call (edit. ie after it become const, really interest in the answer).

No Undefined behavior

/* I imagine this would be okay */

si_non_const = si_non_const + GetMagicValue();

/* Const is promoted here */

const int fparam = si_non_const;

/* Writing to fparam is undefined past here */

f_const(&fparam);

Undefined behavior

/* I imagine writing, after using as const is also not defined, but is fine at this point */

si_non_const = si_non_const + GetMagicValue();

/* Here we now have a constant value that will never be written to */ const int fparam = si_non_const;

f_const(&fparam);

/* I think this would also be UB, even though it's accessed through a different symbol */

si_non_const = si_non_const + GetMagicValue();

Interested in other opinion, maybe will think on later... would it be valid for the compiler to remove that last assignment?

Edit: Sorry, this is unreadable, if you put a space between the not undefined, and undefined it's easier

He means that if you write your library in C it is callable from Python, Java, C++, Ruby, PHP, Python, Perl and more.

I gotta be honest, all of those style suggestions look good until you try them in a non-solo and non-isolated project, and then you see what a mess you created.

We've all been there, as C programmers, and we've all done that in the past, which is why we don't do it anymore