Part of what makes sr.ht great is that it's made of tools that can be used together or separately. If you want to use it for just task tracking, great. If you want to use it for task tracking, git repo, and CI/CD, that's fine. If you want to use it for task tracking on a project that keeps code on github and does CI on gitlab... It still works great:)
I love the simple and lightweight interface, but everything is hard to discover.
Sourcehut? Sounds great- I'd love to replace my Gogs/gitlab instance with something more lightweight. Let's download the source and run it.
I guess click on "git" on https://git.sr.ht/? Wait that's where I already am with no indication that that is the selected tab.
Ok maybe the link for sourcehut? https://sourcehut.org/
Cool. There's some links about pricing, ignore that and click on "100% free and open source software"
Now I am just at a list of what appears to be about 20 repos, all with helpful names like sr.ht-apkbuilds.
I can tell that this person has put a ton of work into making something that is probably fantastic, but it is really all presented in an undiscoverable way. I still have no idea what language this project is written in, how to deploy or maintain it.
I assume https://git.sr.ht/~sircmpwn/git.sr.ht might be what I want, but it still looks like the inscrutable mess that reminds me of hgweb. There's not even a readme on the first page, let alone the source or anything useful. There's a link to https://man.sr.ht/git.sr.ht/installation.md. Which looks like it might be what I want, but I guess I'm old and at this point I've lost interest.
I'm definitely being crotchety, but I wish this information was organized in a more useful way. I can tell Drew has put a lot of time into it, but I don't feel like it is being shared in an effective way. And I would definitely never pay for software like this. Please someone tell me I'm crazy and this UI makes perfect sense to them.
It sounds like you're going to the main page, expecting to download it and deploy it yourself.
It isn't surprising that the main interface is pointing you to _use_ it, rather than deploy it.
If you click on the help hub, _man_, you'll find what you're looking for straight away:
> Hacking on or deploying sourcehut yourself? Resources here.
---
> I guess click on "git" on https://git.sr.ht/? Wait that's where I already am with no indication that that is the selected tab.
That's incorrect. If you look to the left of the nav bar, you'll see some text with red highlighting exactly where you are.
> I still have no idea what language this project is written in, how to deploy or maintain it.
If you click the dev resources link, then you'll find this nice and obvious quote:
> sr.ht core is a Python package that provides shared functionality across all sr.ht services. It also contains the default templates and stylesheets that give sr.ht a consistent look and feel.
> If you look to the left of the nav bar, you'll see some text with red highlighting exactly where you are.
That looks part of the "logo", not part of the navbar. There is at most a minimal difference in the actual "tabs". Of course the reason is that this isn't actually a navbar/tabs but a list of applications offered by sourcehut, this is really noticeable if you click on git when you're at an actual git repository (e.g. https://git.sr.ht/~sircmpwn/scdoc) note that the red text highlighting where I am already says git, so clicking on git shouldn't do anything if it was actually a tab bar, but in reality it navigates to https://git.sr.ht/
I always wonder why it doesn't support git push over https?
See https://git.sr.ht/~sircmpwn/git.sr.ht , and find "Clone" section. It said https is read-only, only git protocol supports write.
This particular code isn't about the post. It's about Bournegol, which doesn't actually exist anymore, and is actually quite hard to track down any examples of.
It's...not, though? The Bourne Shell was released under a free license years ago along with the rest of v7, and it's just a macro hack. Very much still exists, and pretty easy to find.
On C language an expression which evaluates to any non-zero value is considered as True. So for example this kind of statement would not likely behave as intended:
To emphasise: This is about Bournegol. Nothing to do with this post.
> Can you explain why?
Because it isn't how most C libraries expect true/false to be defined.
stdbool in C99 standardized things a bit, but before then what was generally accepted was:
> true is 1
> false is !true (Often 0 in practice).
Which means that any trivial:
if(true) { ... }
Won't work under Bournegol. Instead you _need_ to compare when doing an if statement.
So the C-programmer is easily tripped up. False will work as expected, but True won't... All the time. There may be times it does work. Leaving the programmer throwing their hands in the air.
Most cases I've seen accept anything as true as long as the LSB is 1, and quite strictly 0 as false. Everything else is up in the air. The value -1 is definitely true. :)
As far as I know, std library specifically uses the word "nonzero" in the documentation to denote non-false value. Therefore you should be using !, &&, || for any boolean ops, but never == nor !=
I know it's bad preprocessor magic, but I kinda liked that. I thought about hacking together a quick "Oberon-ish" to JS "transpiler" for a while, of course going along with a decidedly Wirth-ian code style. I might call it "werenotwirthy".
But there's also the appeal of the dreaded Incunabulum...
While I'm not a fan of the specific changes shown in this article, I do agree with the principle of "remove boilerplate when possible". I found that the largest amount of boilerplate I ever wrote was in main() to parse the command line, and to that end I wrote a "magic getopt", which handles both short and long options in-line without external tables (https://www.daemonology.net/blog/2015-12-06-magic-getopt.htm... ); and PARSENUM, which handles the common cases of parsing human-readable values while appropriately checking for overflow (https://github.com/Tarsnap/libcperciva/blob/master/util/pars...).
GNU lambdas are incredibly evil. In order for lambdas to capture their environment and yet still be available as a function pointer, the compiler makes the stack executable and stores the trampoline code on the stack.
I found this one really fascinating, they're using both statement expression and nested functions. Their (reformatted) example of:
int (*max)(int, int) =
lambda(int, (int x, int y) { return x > y ? x : y; });
macro-expands to
int (*max)(int, int) =
({ int _(int x, int y) { return x > y ? x : y;}; });
So they have a statement-expression with just one statement in it - the value of that statement is the value of the whole statement-expression. And the one statement inside the statement expression is a declaration of a nested function named _. Statement-expressions decay their return types, so that function gets converted to a function pointer. And thus your "lambda" is a pointer to a GCC nested function.
Notice the second underscore at the end? The compound statement contains a nested function definition followed by an expression statement which "returns" the function just defined. The function definition alone wouldn't work.
A lambda that does not close over its environment is not really a true lambda. It's just a normal function with function scope. I suspect we have some difference in terminology difference: what I call lambda is what you call nested functions. I hate it when there are those kind of trivial terminology differences.
You can do that with this. Because it does technically contain a nested function called _ it's just GCC usually makes that function a normal function if it contains no variables from the parent's scope.
If you reference the outer scope inwards, however, you will end up with an executable stack. And you won't have a borrow checker to tell you the the value that the lambda mentions is no longer at the same address. In fact, you have no flags to warn you of that event.
C++ has lambdas. GNU-C has a hack that is truly terrifying to behold if you use it to the full power.
I've already said this a couple other places but I really wanted to say: "This is amazing and it would be hilarious if you wrote a CNoEvil vs. BOURNEGOL head to head article".
When I started learning C++, there was't a C++ compiler available for my Atari ST (late 80s), there was only Borland C. So instead I used the C preprocessor to emulate classes, virtual functions etcetera. Not everything could be implemented this way, but it looked like C++ close enough for me to learn it.
That's basically how C++ was originally created, or the prototype, "C with Classes", albeit with a custom preprocessor. [0]
> In October of 1979 I had a pre− processor, called Cpre, that added Simula− like classes to C run-ning and in March of 1980 this pre− processor had been refined to the point where it supported onereal project and several experiments.
Recognising that you could do it that way is kinda awesome. Maybe not entirely uncommon, but you drafted a powerful bit of software yourself.
Thanks, awesome paper (which remind me that I should read the ARM at some point).
Interesting stuff:
"Cfront [the fist c++ compiler] was (and is) a traditional compiler front− end performing a complete check of the syntax and semantics of the language"
"[...] the C compiler is used as a code generator only. [...]. I stress
this because there has been a long history of confusion about what Cfront was/is. It has been called a preprocessor because it generates C, and for people in the C community (and elsewhere) that has been taken as proof that Cfront was a rather simple program – something like a macro preprocessor."
Cfront being a preprocessor is something that gets repeated often. As you correctly point out, cpre was the preprocessor and it wasn't realy C++ yet.
> C-- (pronounced cee minus minus) is a C-like programming language. Its creators, functional programming researchers Simon Peyton Jones and Norman Ramsey, designed it to be generated mainly by compilers for very high-level languages rather than written by human programmers. Unlike many other intermediate languages, its representation is plain ASCII text, not bytecode or another binary format.[1][2]
> There are two main branches of C--. One is the original C-- branch, with the final version 2.0 released in May 2005.[3] The other is the Cmm fork actively used by the Glasgow Haskell Compiler as its intermediate representation.[4]
Yes. In addition to C--, there is a long tradition of FP (and not only) languages targeting C as a (portable) back end representation. That's how many scheme compilers worked for example. LLVM itself at some point had a C backend.
A really good example of this is the implementation of Objective-C. I believe even the original C++ implementation by Bjarne Stroustrup were also C macros.
This works for a literal, but the author was probably thinking of "print a string that comes from somewhere else" where you do the first thing to avoid format characters to be interpreted.
The point is, for simple things, to not have to specify how they appear.
> Well... Because it should have been
> printf("Hello, World!\n");
No. You don't really want to do that. If you're doing that, use puts [0] . All this requires is a modification to one string in memory and you have an injection vulnerability.
That's not UB, that's implementation dependent, AFAIK the C standard says nothing about read-only memory. Attempting to modify a string literal is indeed UB but that would only happen if an attacker managed to attempt to modify the string, not when the program is used normally.
Other important security features like N^X are also not specified in the C standard either, so what's the point of worrying about just printf format strings?
TBH it’s not pedantic to understand the difference between undefined, implementation-defined, and unspecified behavior. It’s part of knowing the language. One of my standard interview questions for C candidates is to ask them to describe and provide an example of each.
Is there really a meaningful difference between implementation-defined and unspecified? I'd say they're shades of gray based on how pedantic the compiler documentation is.
Is it really not UB to attempt to modify RO things? Typically (on major implementations, e.g. GNU/Linux or MSVC/Windows) it will crash, and I don't think it is allowed to crash on non-UB things?
By that same logic, puts("Hello, world!"); is also vulnerable to DoS attack and information leak since someone could have removed the NUL terminator at the end of the string and have puts() read uninitialized/unmapped memory. Which is absurd logic.
In a lot of cases the attacker can only write to a limited range of memory addresses. If that string happens to fall in that range, they can use it to write to other addresses and/or find out where in memory certain things are stored.
So their ability to write to a limited range of addresses can be extended to a larger range.
In order to modify that string, even in RW pages, the attacker already has to have access, at which point the point is moot. It's like saying "if you can change memory, then you can change memory"....
They are nearly equivalent in terms of functional security.
Function isn't everything though. One example shows an awareness of the security issue and good habit being used despite the low impact. I'd argue that there is a security benefit to using one over the other.
Additionally, it's not as simple as saying "if you can change memory, then you can change memory". Memory exploits are quite often chains of small issues these days and not the simple buffer overflow of old.
For example, being able to overwrite one byte somewhere could lead to the ability to change only part of a variable address. That could be used to redirect a write to the constant string in memory.
Sure it's contrived, but scenarios like this do happen.
shows an awareness of the security issue and good habit being used.
printf("%s\n", "Hello, World!");
shows that you think "%s\n\0Hello, World!" (or however the compiler decides to lay out those strings) can't be overwritten with "%p%nHello, World!" (or something to that effect), but "Hello, World!\n" somehow can.
We've spent the last 20 years cleaning up after the shoddy work of people (like you) who think avoiding the deficiencies of a thin wrapper over assembly is just a matter of good habits, rather than actually understanding what the hell they're doing.
And breaking up constants into misordered, mishmashed fragments isn't even a good habit in the first place.
Edit: Come to think of it, given that the original complaint was:
> > printf("Hello, World!\n");
> [...] All this requires is a modification to one string in memory and you have an injection vulnerability.
There's also the fact that it's you who is arguing in bad faith, since a: habit wasn't part of it to begin with, and b: you haven't given any example of a case where a habit of writing `printf("%s\n","<some text>");` rather than `printf("<some text>\n");` is useful for anything whatsoever, security or otherwise.
It's also not defined whether the executable code is in RO memory or RW memory. By your argument, we should also be concerned that the attacker could modify the code directly.
No, a format string attack. If you replace the start of the string with various specifiers, you can lift out pointer addresses and write to them. You can't do that with puts. Worst you can do with puts is read.
puts()'s attack surface is smaller than printf()'s.
This is not how your message appeared to me - "printf() is vulnerable to injections, use puts() instead". Both are vulnerable to "unintended read()-s".
printf is vulnerable to both read and _write_ attacks when you misuse it by only supplying the single argument. It's vulnerable to injections that can lead to remote execution and all sorts of CVEs.
puts is sometimes vulnerable to read attacks, but not often.
GCC automatically replaces printf("foo\n") with puts("foo") even with -O0. Clang does it too, albeit I have to enable optimizations: https://godbolt.org/z/drw4xP . As a result I never use puts for literal strings, this way if I want to add dynamic parameters later I don't have to change the function call.
I'm pathologically lazy.
Also as others point out typically the literal string will be in a ro segment so tampering with it won't be easy unless the code runs in a rather exotic environment.
The good practice that you seem to have read about and badly misunderstood is that the format string argument to a printf family function should always be a string literal right there in the code calling it. The concept of changing printf("foo") to printf("%s", "foo") for 'security' against your own hardcoded string literal is more bizarre than any of the intentionally bizarre convolutions in your posted project.
Specifically, printf is an oddball function because it uses the varargs mechanism, and the whole format strings mechanism is inherently risky because it effectively bypasses the type system and says "trust me." Back when I was learning C, on a Mac with THINK C, misusing printf was a sure-fire way to crash the computer very quickly, especially since misaligned accesses of 16-bit or 32-bit words caused crashes. Compilers now go to a great deal of trouble to try to do additional safety and consistency checks.
Don't get my wrong, I grew up using printf, and it is massively useful. But it was designed when computers were much smaller and simpler, and design tradeoffs were made back then that probably wouldn't be chosen today. So printf, along with a whole family of related functions, has been a seething mess of a security and safety hole longer than most programmers have been alive.
Sure, but that's varargs being the special cased but, not printf (I've written printf implementations for some ebedded systems, it's always just regular C code).
The popular C compilers have a feature where they will do some additional type checking on the arguments passed to "format" functions. You can mark your own functions with this attribute.
printf is not an oddball function. Also, typechecking format strings in general does not have to be that complicated. They are still used in golang.
Of all the security pitfalls of C, the format string design of printf is way down the list. As others have noted, printf is not what makes the C type system weak.
Firstly, I think you're taking this waaaayyyy more seriously than it was intended. Secondly
double foo = 1.2;
printf(foo);
puts(foo);
won't compile, while
double foo = 1.2;
display(foo);
works fine.
Incidentally I actually think display is the only thing on this list that is probably worth using, you could also probably extend it to accept multiple arguments relatively simply as well.
My friend served as a military officer and told me a story. Every evening before lights out, he had to count soldiers via a roll call, a 10-minute routine. If someone coughed during that (no matter what intent), then suddenly many soldiers began to cough, and that ruined everything. The only solution he figured out to remain legal/moral was to pause and start it all over if someone coughs.
191 comments
[ 3.5 ms ] story [ 232 ms ] threadAnonymous non-user people allowed on issue tracker that doesn't have to be linked to any repo? Awesome. (And you can export easily.)
Easy to combine multiple build projects into a single build that can be kicked off by any one of the projects? Sweet.
Drew is also really responsive if you run into any problems.
Sourcehut? Sounds great- I'd love to replace my Gogs/gitlab instance with something more lightweight. Let's download the source and run it. I guess click on "git" on https://git.sr.ht/? Wait that's where I already am with no indication that that is the selected tab. Ok maybe the link for sourcehut? https://sourcehut.org/ Cool. There's some links about pricing, ignore that and click on "100% free and open source software" Now I am just at a list of what appears to be about 20 repos, all with helpful names like sr.ht-apkbuilds.
I can tell that this person has put a ton of work into making something that is probably fantastic, but it is really all presented in an undiscoverable way. I still have no idea what language this project is written in, how to deploy or maintain it.
I assume https://git.sr.ht/~sircmpwn/git.sr.ht might be what I want, but it still looks like the inscrutable mess that reminds me of hgweb. There's not even a readme on the first page, let alone the source or anything useful. There's a link to https://man.sr.ht/git.sr.ht/installation.md. Which looks like it might be what I want, but I guess I'm old and at this point I've lost interest.
I'm definitely being crotchety, but I wish this information was organized in a more useful way. I can tell Drew has put a lot of time into it, but I don't feel like it is being shared in an effective way. And I would definitely never pay for software like this. Please someone tell me I'm crazy and this UI makes perfect sense to them.
It isn't surprising that the main interface is pointing you to _use_ it, rather than deploy it.
If you click on the help hub, _man_, you'll find what you're looking for straight away:
> Hacking on or deploying sourcehut yourself? Resources here.
---
> I guess click on "git" on https://git.sr.ht/? Wait that's where I already am with no indication that that is the selected tab.
That's incorrect. If you look to the left of the nav bar, you'll see some text with red highlighting exactly where you are.
> I still have no idea what language this project is written in, how to deploy or maintain it.
If you click the dev resources link, then you'll find this nice and obvious quote:
> sr.ht core is a Python package that provides shared functionality across all sr.ht services. It also contains the default templates and stylesheets that give sr.ht a consistent look and feel.
That looks part of the "logo", not part of the navbar. There is at most a minimal difference in the actual "tabs". Of course the reason is that this isn't actually a navbar/tabs but a list of applications offered by sourcehut, this is really noticeable if you click on git when you're at an actual git repository (e.g. https://git.sr.ht/~sircmpwn/scdoc) note that the red text highlighting where I am already says git, so clicking on git shouldn't do anything if it was actually a tab bar, but in reality it navigates to https://git.sr.ht/
However, when I see landmines like these:
I might just hide instead of touching it.https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh
> Can you explain why?
Because it isn't how most C libraries expect true/false to be defined.
stdbool in C99 standardized things a bit, but before then what was generally accepted was:
> true is 1
> false is !true (Often 0 in practice).
Which means that any trivial:
Won't work under Bournegol. Instead you _need_ to compare when doing an if statement.So the C-programmer is easily tripped up. False will work as expected, but True won't... All the time. There may be times it does work. Leaving the programmer throwing their hands in the air.
Except when being used as a comparison to any of the std utilities.
I might just hide instead of touching it.
This code (the Bourne Shell source) is actually the reason why the IOCCC was created.
But there's also the appeal of the dreaded Incunabulum...
But not when printing to stdio.h text streams; \n turns into the right line ending.
Only on some, but not all, compilers. I got varying behaviour until I went ahead and did it myself.
C++ lambdas don't suffer from this problem.
IIRC compound statements, like I've presented, don't use trampolines. Nested functions definitely do, but that isn't quite what we're doing here.
GCC _should_ compile using descriptors for the compound statements that lambda is expanding to instead of using trampolines.
Works. There's no trampoline present.I'd try myself but my gcc doesn't recognize -fno-trampolines.
If you reference the outer scope inwards, however, you will end up with an executable stack. And you won't have a borrow checker to tell you the the value that the lambda mentions is no longer at the same address. In fact, you have no flags to warn you of that event.
C++ has lambdas. GNU-C has a hack that is truly terrifying to behold if you use it to the full power.
There's also all the examples [1].
[0] https://git.sr.ht/~shakna/evilshell
[1] https://git.sr.ht/~shakna/cnoevil3/tree/master/examples
<3
However, Ada's main benefits - the incredible type system, don't exist at all here. CNoEvil is a giant shotgun pointed directly between your legs.
> In October of 1979 I had a pre− processor, called Cpre, that added Simula− like classes to C run-ning and in March of 1980 this pre− processor had been refined to the point where it supported onereal project and several experiments.
Recognising that you could do it that way is kinda awesome. Maybe not entirely uncommon, but you drafted a powerful bit of software yourself.
[0] http://www.stroustrup.com/hopl2.pdf
Interesting stuff:
"Cfront [the fist c++ compiler] was (and is) a traditional compiler front− end performing a complete check of the syntax and semantics of the language"
"[...] the C compiler is used as a code generator only. [...]. I stress this because there has been a long history of confusion about what Cfront was/is. It has been called a preprocessor because it generates C, and for people in the C community (and elsewhere) that has been taken as proof that Cfront was a rather simple program – something like a macro preprocessor."
Cfront being a preprocessor is something that gets repeated often. As you correctly point out, cpre was the preprocessor and it wasn't realy C++ yet.
https://en.wikipedia.org/wiki/C--
> C-- (pronounced cee minus minus) is a C-like programming language. Its creators, functional programming researchers Simon Peyton Jones and Norman Ramsey, designed it to be generated mainly by compilers for very high-level languages rather than written by human programmers. Unlike many other intermediate languages, its representation is plain ASCII text, not bytecode or another binary format.[1][2]
> There are two main branches of C--. One is the original C-- branch, with the final version 2.0 released in May 2005.[3] The other is the Cmm fork actively used by the Glasgow Haskell Compiler as its intermediate representation.[4]
(I ended up using this in a job once. They didn’t hire me back...)
[0] https://todo.sr.ht/~shakna/CNoEvil3/9
One can do something like
and claim that C is awful and that is so much better.[0] https://gist.github.com/shakna-israel/4fd31ee469274aa49f8f97...
All of these are valid:
The point is, for simple things, to not have to specify how they appear.> Well... Because it should have been
> printf("Hello, World!\n");
No. You don't really want to do that. If you're doing that, use puts [0] . All this requires is a modification to one string in memory and you have an injection vulnerability.
[0] http://www.cplusplus.com/reference/cstdio/puts/
If we're being pedantic, it's _unspecified behaviour_. The implementation isn't required to document how it would behave.
By modifying the start of that string, you can begin reading and writing to various parts of the stack.
Whilst implementations may inline that string into a RO memory region - that's not defined behaviour, so you shouldn't depend on it.
[0] https://owasp.org/www-community/attacks/Format_string_attack
> Originally thought harmless, format string exploits can be used to crash a program or to execute harmful code.
They are not the same as puts. Puts can allow you to potentially read memory.
A format string attack can allow you to write to memory.
[0] https://en.wikipedia.org/wiki/Uncontrolled_format_string
So their ability to write to a limited range of addresses can be extended to a larger range.
In order to modify that string, even in RW pages, the attacker already has to have access, at which point the point is moot. It's like saying "if you can change memory, then you can change memory"....
The article’s author (posting here on HN) is grossly mistaken.
Function isn't everything though. One example shows an awareness of the security issue and good habit being used despite the low impact. I'd argue that there is a security benefit to using one over the other.
Additionally, it's not as simple as saying "if you can change memory, then you can change memory". Memory exploits are quite often chains of small issues these days and not the simple buffer overflow of old.
For example, being able to overwrite one byte somewhere could lead to the ability to change only part of a variable address. That could be used to redirect a write to the constant string in memory.
Sure it's contrived, but scenarios like this do happen.
Yes,
shows an awareness of the security issue and good habit being used. shows that you think "%s\n\0Hello, World!" (or however the compiler decides to lay out those strings) can't be overwritten with "%p%nHello, World!" (or something to that effect), but "Hello, World!\n" somehow can.We've spent the last 20 years cleaning up after the shoddy work of this exact attitude.
And breaking up constants into misordered, mishmashed fragments isn't even a good habit in the first place.
Edit: Come to think of it, given that the original complaint was:
> > printf("Hello, World!\n");
> [...] All this requires is a modification to one string in memory and you have an injection vulnerability.
There's also the fact that it's you who is arguing in bad faith, since a: habit wasn't part of it to begin with, and b: you haven't given any example of a case where a habit of writing `printf("%s\n","<some text>");` rather than `printf("<some text>\n");` is useful for anything whatsoever, security or otherwise.
Nothing.
Neither is more secure, all modern compilers put both “%s” and “Hello, world!” in rodata sections.
Your understanding of practical format string attacks is misguided.
This is not the case for RO strings, is it?
printf is vulnerable to both read and _write_ attacks when you misuse it by only supplying the single argument. It's vulnerable to injections that can lead to remote execution and all sorts of CVEs.
puts is sometimes vulnerable to read attacks, but not often.
I'm pathologically lazy.
Also as others point out typically the literal string will be in a ro segment so tampering with it won't be easy unless the code runs in a rather exotic environment.
Specifically, printf is an oddball function because it uses the varargs mechanism, and the whole format strings mechanism is inherently risky because it effectively bypasses the type system and says "trust me." Back when I was learning C, on a Mac with THINK C, misusing printf was a sure-fire way to crash the computer very quickly, especially since misaligned accesses of 16-bit or 32-bit words caused crashes. Compilers now go to a great deal of trouble to try to do additional safety and consistency checks.
Don't get my wrong, I grew up using printf, and it is massively useful. But it was designed when computers were much smaller and simpler, and design tradeoffs were made back then that probably wouldn't be chosen today. So printf, along with a whole family of related functions, has been a seething mess of a security and safety hole longer than most programmers have been alive.
And it's C; everything bypasses the type system and says "trust me". Memory allocation bypasses the type system and says "trust me".
If you want strong typing (!= static typing), C is not the language you should be using, printf or no printf.The popular C compilers have a feature where they will do some additional type checking on the arguments passed to "format" functions. You can mark your own functions with this attribute.
See the format attribute https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute....
printf is not an oddball function. Also, typechecking format strings in general does not have to be that complicated. They are still used in golang.
Of all the security pitfalls of C, the format string design of printf is way down the list. As others have noted, printf is not what makes the C type system weak.
Incidentally I actually think display is the only thing on this list that is probably worth using, you could also probably extend it to accept multiple arguments relatively simply as well.
The first proposed macro displayln is the archetype of malpractice. What if I want to do:
if(some_condition) displayln("enjoy debugging that");
etc etc... almost all proposed changes seem to be awful ?
> What if, for a moment, we forgot all the rules we know. That we ignore every good idea, and accept all the terrible ones.
evil.h == arduino.h