> And even if everything is correct, it's has to parse a string at runtime. I consider that alone unaesthetic.

Technically, it doesn’t have to do that. If a program includes the header declaring printf using the <> header defined in the standard and then calls printf the compiler is allowed to assume that the printf that the program will be linked to will behave according to the standard, and need not compile a call to printf. It can generate code that behaves identically.

A simple example is gcc converting a printf with a constant string to a puts call (https://stackoverflow.com/questions/25816659/can-printf-get-...)

> If you don't care about the limits of the tech you won't be able exceed what you think is possible.

Did you propose/implement/release something better than printf?

> I'm time and time again amused how anti intellectual and outright hostile to technological progress the programming profession is. programmers, out of all of them.

Perfect is the enemy of good. Some people talk about getting work done, some people get the actual work done and move on.

>Did you propose/implement/release something better than printf?

This is what the article is about? Things much better that printf are a dime a dozed and available since 20 years.

>Some people talk about getting work done,

Like this article does? While you busy arguing that you could do the same thing, but much worse?

> Perfect is the enemy of good. Some people talk about getting work done, some people get the actual work done and move on.

In my experience, people with this motto generally produce code which frustrates the whole team.

Being a perfectionist is toxic in its own way, though.

There needs to be a balance. I think that balance is to think and plan a few steps ahead (not too much, as it's counter productive) before hitting the keyboard. I know this sounds a bit like a "d'oh, of course" but it really—and unfortunately—isn't something that people practice; they just think they do.

Lets consider #embed which is new for C23. It allows you to import binary blobs of data into a C program at compile time. Like say if you want to import an image or sound file or a table.

How hard was that to implement? Seriously no reason it couldn't have been part of C89. Why wasn't it? Because the compiler writers and the C++ standards committee have no personal use for it. It took 40 years of waiting and five years to get it just barely past the standards committee. If you think no one would strenuously oppose a feature like embed you'd be wrong.

Those guys also have no interest in printf type functions. And improving printf would be a lot more work than implementing #embed.

That’s neat - Borland C had the same thing with the `emit()` pseudo-function with their C89 compiler. I guess Borland’s compiler writers wanted it more than gcc’s?

You can use ld to turn any file into an object file:

    ld -r -b binary -o foo_txt.o foo.txt

foo_txt.o then has these symbols:

extern const char _binary_foo_txt_start[]; extern const char _binary_foo_txt_end[]; extern const void *_binary_foo_txt_size;

So you need to write your own declarations (it doesn't generate a header file).

_binary_foo_txt_size is weird and has to be used as: (size_t)&_binary_foo_txt_size

Or use (size_t)(_binary_foo_txt_end - _binary_foo_txt_start) instead.

Consider the difference between what a compiler does and say a video game or embedded firmware. Compilers are old school batch mode programs that import data from a file, parse it, transform it to something, and emit it as a file.

>some people get the actual work done and move on

These people's "actual work" often ends up causing endless streams of security vulnerabilities and bugs too.

Most of the same people you are referring to don't seem to believe that security vulnerabilities exist or are important enough to care about for some reason, but in the real world these are very important issues.

> These people's "actual work" often ends up causing endless streams of security vulnerabilities and bugs too.

On the other hand, we have people that apparently wouldn't make a program if they are not guaranteed (by another human being) that it will be safe.

If those people generating bugs and vulnerabilities would had to sit tight waiting for someone to make a safe language to do anything, today the world would be 40 years or more behind.

(safe languages that, sarcastically, were created using all those unsafe tools and insfrastructure)

Also in this real world a trillion of printf are being output right now, and will be for a long long time. Is the world falling apart?

You can also list all the printf CVEs but... how many println! are being output?

> Perfect is the enemy of good.

Sure, but we're talking about printf here. printf is manifestly mediocre.

I guess 'perfect is the enemy of mediocre' doesn't have quite the same ring.

Everything has security implications in c, but printf isn't particularly bad. Common use of it involves a fixed format string specified at the call site. This prevents the most dangerous use of it (user specified format string) and also allows the compiler to detect when the format string doesn't correspond to the types of the arguments. Both these failures can be converted into compile time errors in common compilers. Printf, for all C's other faults, really isn't that bad.