Off topic, but in today's bitter and divided world, it's reassuringly wholesome that people can still get together to recite the alphabet in GitHub comments.
Let's Destroy C
141–150 of 192 posts
Re: Let's Destroy C
#142Earlier quoted context omitted.
> remove some of the undefined behaviors, There was a great talk from a C/C++ compiler writer about why you can't remove undefined behaviors while at the same time keeping C like speed. Simple example: accessing an array past it's end it's undefined behaviour. If you want to remove this, you need to add bounds checking (either to raise an error or to just return 0).
> you can't remove undefined behaviors while at the same time keeping C like speed. This is absolutely correct. The specs of C allow so much undefined behavior in order to let the compiler just emit the instructions for the arithmetic operation or memory access or whatever. For edge cases like overflow and bounds, C deliberately says "not my problem" and you just get whatever that hardware architecture happens to do…
It's more that things were left undefined for portability and compiler authors (ab)used them for optimization enough for that to become de facto true (especially now that portability is easier).
Re: Let's Destroy C
#143I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development) There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand. Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support…
Have you looked into Zig (https://ziglang.org/)? It's a little more than what you've asked since it does support compile time generics. But is specifically targeted at removing undefined behavior and improving safety.
Re: Let's Destroy C
#144I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development) There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand. Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support…
> In general, anything that was added to a language to support generics or to hide pointers and memory management from the developers on a language that isn't a lisp has only produced more harm than good.
I understand why you would want explicit memory management, but what specifically is harmful about generics?
Re: Let's Destroy C
#145Reminds me of Arthur Whitney's k.h[1]
Example:
// remove more clutter
#define O printf
#define R return
#define Z static
#define P(x,y) {if(x)R(y);}
#define U(x) P(!(x),0)
#define SW switch
#define CS(n,x) case n:x;break;
#define CD default
Re: Let's Destroy C
#146// Original macro hack by Robert Elder (c) 2016 Described also back in 2000 on https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
And as Simon Tatham points out there, Tom Duff invented it in the 80s, but only hinted at it rather than publish it.
Re: Let's Destroy C
#147The end result reminds me of Julia. Enough to make me wonder if there's something like it underneath Julia somewhere, or if that's how it started (unfortunately I don't have time to really dig in to it right now).
Re: Let's Destroy C
#148I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development) There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand. Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support…
> remove some of the undefined behaviors, There was a great talk from a C/C++ compiler writer about why you can't remove undefined behaviors while at the same time keeping C like speed. Simple example: accessing an array past it's end it's undefined behaviour. If you want to remove this, you need to add bounds checking (either to raise an error or to just return 0).
Only if you define it to be something dumb like an error or returning 0. It should instead be defined as the hardware behavior: a load to the resulting linearly-calculated address which enters an implementation-defined exceptional state (e.g. SIGSEGV/SIGBUS) if that address does not represent readable memory.
Re: Let's Destroy C
#149I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development) There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand. Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support…
I understand it's against the rules to suggest someone hasn't read the article.
But I think it's pretty clear from this comment that the article has zero to do with the posted article. The article's title was provocative and humorous, bc it's abt using C in a very peculiar way. It's not about the tired argument of "should we replace C with Rust/etc." which the above poster and many others have glommed onto. This waterfall of irrelevant comments has no place next to this article which is abt a very specific, interesting set of techniques.
Re: Let's Destroy C
#150Earlier quoted context omitted.
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.
> That's not UB, that's implementation dependent, AFAIK the C standard says nothing about read-only memory. If we're being pedantic, it's _unspecified behaviour_. The implementation isn't required to document how it would behave.
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.