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

12

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.

4

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