How do you not use const for arguments of data types that are too costly to pass by value?
Usually if it is too costly, then you pass it via a pointer.
My personal C coding style as of late 2023
131–140 of 466 posts
Re: My personal C coding style as of late 2023
#132Earlier 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?
For example, Microchip XC16 [1]. It is GCC with changes to support their PIC processors. Some of the changes introduce bugs, for example (at least as of v1.31) the linker would copy the input linker script to a temporary location while handling includes or other pre-processor macros in the linker script. Of course if you happen to run two instances at exactly the same time one of them fails.
As far as the licensing part goes they give you the source code, but last time I tried I could not get it to compile. Kind of lame and sketchy in my opinion.
[1] https://www.microchip.com/en-us/tools-resources/develop/mpla...
Re: My personal C coding style as of late 2023
#133Earlier quoted context omitted.
> signed sizes are an extremely surprising abstraction break that are just asking for disaster. Bjarne Stroustrup wrote a detailed memo advocating for signed sizes: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14...
Eh, I hard disagree with this memo. He's either dismissing or unaware of the biggest advantage of unsigned types, namely they make invalid state unrepresentible. And essentially all of his criticism of unsigned types is really criticism of the sloppy way old C and C++ compilers let you mix signed and unsigned numbers in math operations. Modern C/C++ compilers can and will warn you (quite aggressively) if you mix sign…
The advantage of using signed types is that you can reliably find overflow bugs using UBSan and protect against exploiting such errors by trapping at run time. For unsigned types, wrap-around bugs are much harder to find and your program will silently misbehave.
Re: My personal C coding style as of late 2023
#134Earlier quoted context omitted.
i never thought about that, saving bytes even in symbols
Yeah, old C compilers would only look at the first 6 characters of a name, and the rest were insignificant. That's how you get nanrs like "strcpy" and "malloc" instead of something like "string_copy" or "mem_allocate" (I still think "memory_allocate" would be long enough to be annoying to type).
One of last vestiges of this fact AFAIK was libjpeg, which had a macro NEED_SHORT_EXTERNAL_NAMES that shortens all public identifiers to have unique 6-letter-long prefixes. Libjpeg-turbo nowadays has removed them though [1].
[1] https://github.com/libjpeg-turbo/libjpeg-turbo/commit/52ded8...
Re: My personal C coding style as of late 2023
#135Earlier quoted context omitted.
I'm afraid you are mistaken. In particular for pointers, const does not guarantee that the memory at the location pointed to won't change. Const only guarantees that the address itself doesn't change.
Should perhaps be int Foo_bar(const Foo * self);
`const Foo*` and `Foo const*` are exactly the same and just a question of style (east-const vs. west-const)
Not to be confused with `Foo *const`
Re: My personal C coding style as of late 2023
#136Interesting 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 showin…
Finding the right abstraction isn't always easy. Sometimes if I just put it down and let it slosh around in my brain for a few days, it comes to me.
Like your idea of pruneDeadProjects()!
Re: My personal C coding style as of late 2023
#137Earlier quoted context omitted.
Also, `#define countof(a) (sizeof(a) / sizeof(*(a)))` is unsafe since the arg is evaluated twice.
Arguments to sizeof aren’t actually evaluated (except for variably-modified-types, AKA VLAs, but don’t use those).
Please use those. They are useful, make code clearer, improve bounds checking, ...
Don't let attackers influence the size of a buffer (neither for VLAs nor for heap allocations).
Re: My personal C coding style as of late 2023
#138Earlier quoted context omitted.
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.
[deleted]
Re: My personal C coding style as of late 2023
#139IMO, defining your own types is one step too far. Now everyone who is already familiar with C types has to learn your own quirky system to understand one program. I think it does probably make sense to be specific about the sizes though e.g. using uint32_t over just uint (and expecting to receive some architecture-dependent size you might not get with uint.) These types should be defined in the right header (I think…
they're not quirky types in the least...
In isolation, they're not crazy.
But much C code is bringing in library headers which contain their author's own pet choices for these, which inevitably are not the same and the result is extremely confusing when you have that in play as well as the stdint.h ones.
The kernel contains a mixture of "pet" types like u32 and stdint ones, it's already confusing.
He also does make a "crazy" choice later to call his string class "s8" which clashes with his nomenclature here.
Re: My personal C coding style as of late 2023
#140I 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.
It wasn't clear to me if he's talking about const as a variable declaration qualifier - I never used it - or const in pointer types, which is very useful.