Pretty much agree with most of this. My own personal evolved style is pretty similar. I'm suspect this kind of pragmatic style offends the theoretic and the academic. That can be intimidating. I'm glad at least one other person out there is like me.
My personal C coding style as of late 2023
121–130 of 466 posts
Re: My personal C coding style as of late 2023
#122Parameters 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…
Agreed; const is one of those features that is so good I wish a lot of other languages (e.g. java) had it.
FWIW, Java does have the "final" keyword.
Re: My personal C coding style as of late 2023
#123looks like u tabstop at 4, i prefer 2. other than that our styles match :)
Re: My personal C coding style as of late 2023
#124Earlier quoted context omitted.
> 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 featur…
My understanding is that the GPL only requires the source code to be made available on request for at least 3 years (or as long as you support the software, if more than 3 years). If you want to require people who want the source to write to you via the Post Office and pay shipping+handling+cost of a disc to receive the source code, I believe this is permitted by the GPL as long as you don't profit off of the cost.
Of course, for almost all practical cases, the source code for a GPLed program is made available as a download off the Internet because the mail order disc route seems really archaic these days and probably would be removed altogether in a GPL version 4 if some prominent company used this loophole to evade the spirit of the GPL. Either that or somebody would jump through your hoops to get the source and just stick it on a public GitHub repo. If you then DMCA that repo, you'd be in violation of the GPL.
If you share an GPLed executable with your friends or with other people at a company, then they'd presumably be able to request the source code. But if you run a Cloud GCC service with your fork, you could get away with keeping your source code proprietary because GCC isn't under AGPL.
Re: My personal C coding style as of late 2023
#125I 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.
And, he also says "I’m not saying everyone should write C this way, and when I contribute code to a project I follow their local style."
Re: My personal C coding style as of late 2023
#126I might just be a grumpy old dev but a lot of this stuff gets an immediate no from me because it’s so unidiomatic. You have to unlearn the accepted way of doing things and you end up with a codebase that is just so foreign to anyone looking at even a small chunk of it, unless they are committed to really learning to do things your way. Everyone knows what a uint32_t is when they see it. The cognitive overhead (until…
I want to both be polite to the OP but also agree. Writing correct C is hard, so I’m not going to knock anyone who found stuff that helps them. But pound defining shit to things you know via your Hungarian notion? Write some elisp. My Haskell programs don’t actually have Unicode lambda in them. Pascal strings? Yeah, that’s probably the better call, but why not use C++ or Rust or something where a bunch of geniuses go…
Too many geniuses spoil the soup. We all see many of thousands of recipes and techniques over the course of our careers and it makes sense that each of us are continuously curating the small subset that we reach for in every project. I enjoy seeing the workbenches of other craftsmen, and nothing here looks unfamiliar.
Arthur Whitney however is nuts.
Re: My personal C coding style as of late 2023
#127> #define sizeof(x) (size)sizeof(x) Technically, it's illegal to #define over a language keyword.
Considering '#defines' are done in a textual pre-precessing by the C pre-processor, they don't know much at all about the C language. You can define out int, long, struct or anything.
I have seen many people redefine 'for' and 'while'. These people often argue that it is an improvement.
cpp
#define sizeof(x) (size)sizeof(x)
sizeof(UU) # 1 ""
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 ""
(size)sizeof(UU)Re: My personal C coding style as of late 2023
#128IMO, 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…
I mean, being a bit glib here, but a lot of programming is dealing with someone else's type system. Moreover, for those of us who write C fairly often, the mnemonics here are familiar. Actually, as custom type systems go, this one is pretty elegant. Reminds me of Rust.
Speaking of type systems, I read glib as g-lib a few times and tried to understand how you were talking about the GNU lib in that sentence.
Re: My personal C coding style as of late 2023
#129Earlier quoted context omitted.
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?
No; it's up to the program author to link against a library that provided back-traces (and maybe install a signal handler to call into that unwinder). Even then, some kind of information needs to be retained in the binary that's normally not (-gmlt comes to mind).
Usually folks attach a debugger to capture a stack trace. Usually the debugger uses debug info to determine where the program is, and it's stack trace. Or it can walk frame pointers. Depends on if either are even used, which is a compile time decision.
Re: My personal C coding style as of late 2023
#130IMO, 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…
It's pretty much the same types you see in Rust or Zig, and I think Linux even uses some of the same types.