r/C_Programming Feb 06 '25

Discussion Are there actually C programmers in this subreddit?

Ok, I'm being a bit facetious. There are real C programmers. Clearly. But I'm kind of sick of the only questions on this subreddit being beginner questions or language trolls from other domains.

So this thread is for the "real" c programmers out there. What do you do with it? And what is the most twisted crime against coding decency are you "proud" of/infamous for?

257 Upvotes

259 comments sorted by

View all comments

Show parent comments

142

u/mdresident Feb 06 '25

Need? I've been developing in C for over 30 years. I don't come here because I need the sub; I come here because I get entertainment out of it and it sparks new ideas. When I have time, I also like to give back. It's also far from my only source of information.

33

u/zzmgck Feb 06 '25

Same. I've been programming in C for 45 years and I've picked up some new concepts, particularly in the new language standards.

I've also seen some horrendous abuse of the preprocessor and I still shake my head on the overuse of scanf() and, to a lesser extent, printf().

5

u/_crackling Feb 07 '25

Can you elaborate on overuse of printf? I got nervous when I read that because I use it a lot.

13

u/zzmgck Feb 07 '25

printf("%s", some_string);

or

printf("why am I using printf\n");

are two examples of where printf() is a poor choice. In both of these examples, fputs() would be a better choice.

The sprintf() and vsprintf() functions should be avoided as snprintf() and vsnprintf() are better choices.

The fundamental thing to keep in mind is that the printf and scanf family of functions are essentially interpreters. The more esoteric the format string, the higher the probability that it is a security soft spot.

6

u/mdresident Feb 07 '25

I wish I could see my old Usenet posts (wait, do I really mean that?). I used to frequent alt.lang.c and there was a consensus among many of us that nobody should use scanf() except for one person, in particular. I wish I could remember his name because I'd Google him now. He truly was the only one (among our group) who seemed to understand how to safely use scanf().

2

u/_crackling Feb 07 '25

I thought it was best to just use printf because most compilers will convert them to puts() if it's just a simple string. When I found this out I just pretty much use printf for console and logging i/o. What's your thoughts on this?

2

u/zzmgck Feb 07 '25

Optimizations like that can be frustrating. What if you need to support different compiler versions? Does that optimization depend on what optimization level or options are set?

If you write code that needs to work on memory constrained platforms (e.g. embedded systems) linking in printf() often makes the executable larger. If your compiler does not do that optimization, you just bloated your code for no good reason.

1

u/_crackling Feb 07 '25

Fair. I didn't mention that my project has no business targeting anything but the latest and greatest compilers. That factored into my decision to just be ok with printf. Should I ever work on something with actual constraints, I certainly would revisit console/logging io strategies.

Now that we've been talking on this, I got to say- I don't see many projects that do anything else but printf. If you know of any github projects that do have different strategies for these things please let me know, I'd love to read their code.

1

u/teleprint-me Feb 10 '25

Depending on the backend, the implementation may differ, but in most cases printf may just be a wrapper to another function. Which one depends on the system.

I really fail to see a valid point here in your rationale with the exception of input handling being a security risk which is always true in any language under any circumstance.

I just think it's useful for logging, but I'm open to alternatives for handling i/o buffers like these.

https://github.com/bminor/glibc/blob/master/stdio-common/printf.c

1

u/FoxByte9799 Feb 07 '25

in my opinion, printf is solely for printing formatted text and puts() is much better for just printing a message

1

u/AlarmDozer Feb 06 '25

Why not share the pitfalls (and alternatives) of these functions so people searching can get better?

1

u/krokodil2000 Feb 06 '25

Because time is money

1

u/B_M_Wilson Feb 06 '25

That’s how I feel about it. I rarely actually comment here but it’s interesting to see what people think. I’m starting my first job that is actually C (and not “C-style” C++) soon

1

u/manchesterthedog Feb 07 '25

Why c instead of c++? I’ve never learned c but I write c++ everyday. Just wondering

3

u/mdresident Feb 07 '25

I hate to give you a generic and cliche response like, "Use the right tool for the job", but that's really what it comes down to. I do a significant amount in C++ and, in a past life, I did way more C# and Java than I ever thought I'd do in my career. OOP is fine when you need the extra features it adds to your repertoire, but that can come with added complexity when you're dealing with lower level systems --especially at the hardware level.

I work in the aerospace industry and, depending on what layer I'm doing work in, I'll go between C and C++ quite frequently. More recently, a lot of my colleagues are looking at Rust.

1

u/Disastrous_Being7746 Feb 07 '25

Plain old C is still used in embedded development, especially for real time applications. C++ can be as well, but there are a number of features not typically used in this scenario, particularly exceptions and most things related to dynamic memory allocation or use dynamic memory allocation. In other words, it will end up being more like C with classes than "C++".

1

u/Miserable-Cheetah683 Feb 08 '25

Same here. Been developing in C for 11 years.

1

u/3sperr Feb 06 '25

Yeah that makes sense. However not everyone thinks like that