I can't help but be reminded of some of the horrifying basic.h and pascal.h macro-filled headers I can remember from long, long ago. Except people actually used those...
Let's Destroy C
101–110 of 192 posts
Re: Let's Destroy C
#102Earlier quoted context omitted.
Format string attacks have occurred in the wild. [0] > 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 an attacker able to write to memory would be able to elevate into the ability to... write to memory. That doesn't sound particularly worrisome.
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.
Re: Let's Destroy C
#103> printf("%s\n", "Hello, World!"); > > That's an awful lot of symbolic syntax. Well... Because it should have been printf("Hello, World!\n"); in the first place? One can do something like printf("%s,%s%c\n", "Hello", "World", '!'); and claim that C is awful and that displayln("Hello, World!"); is so much better.
displayln is a _Generic. All of these are valid: displayln("Hello, World!"); displayln(100); displayln(1.8); 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 vulnerabil…
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.
Re: Let's Destroy C
#104Ah, finally a modern successor to Bournegol: http://oldhome.schmorp.de/marc/bournegol.html
#define TYPE typedef #define STRUCT TYPE struct #define UNION TYPE union Well, that's extremely opinionated. Which I guess is the point. It does seem to add a BASIC-ness to the code. However, when I see landmines like these: #define TRUE (-1) #define FALSE 0 I might just hide instead of touching it.
It's an ALGOL-derivative, not a BASIC-derivative. It's trying to be ALGOL. Bourne was one of the few people to write an ALGOL-68 compiler.
I might just hide instead of touching it.
This code (the Bourne Shell source) is actually the reason why the IOCCC was created.
Re: Let's Destroy C
#105Earlier quoted context omitted.
#define TYPE typedef #define STRUCT TYPE struct #define UNION TYPE union Well, that's extremely opinionated. Which I guess is the point. It does seem to add a BASIC-ness to the code. However, when I see landmines like these: #define TRUE (-1) #define FALSE 0 I might just hide instead of touching it.
Uh... This is serious landmine... I suggest author to change this.
The author is 76, and retired. This is from UNIX v7, before the standardization of C.
Re: Let's Destroy C
#106Earlier quoted context omitted.
Uh... This is serious landmine... I suggest author to change this.
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.
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh
Re: Let's Destroy C
#107This just in: you can write bad code in any language. In this case, that language is the C Preprocessor, already well documented and widely accepted as a Bad Language To Start With. The title of the article is misleading: it's not "destroying C" it's writing Bad Code using the C Preprocessor. It's not destroying C any more than a series of bad puns destroys the English language.
If one has the time, I think its a good exercise to turn a paradigm on its head and see if anything good falls out of the awfulness.
Re: Let's Destroy C
#108Earlier quoted context omitted.
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 doin…
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. :)
One could say that -1 is the truest true, because its two's-complement representation has the most 1s.
Re: Let's Destroy C
#109Those defines remind me of how Bourne shell was originally written using such a system to make the source look more like Algol 68. It might even still be maintained that way in BSD to this day [0].
[0] https://books.google.ca/books?id=9f9uAQAAQBAJ&pg=PA9&lpg=PA9...
Re: Let's Destroy C
#110This just in: you can write bad code in any language. In this case, that language is the C Preprocessor, already well documented and widely accepted as a Bad Language To Start With. The title of the article is misleading: it's not "destroying C" it's writing Bad Code using the C Preprocessor. It's not destroying C any more than a series of bad puns destroys the English language.
> you can write bad code in any language.
But it's more fun to do in C.