Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Destroy C

gist.github.com

Post reply on HN
Print view View original

171–180 of 192 posts

Re: Let's Destroy C

#171

Post by gpderetta »

msla wrote: post #100
userbinator wrote: post #86

Earlier quoted context omitted.

I believe the "modern" term for Cfront would be "transpiler".

I think it could be called a "compiler" if C-- is anything to go by: 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,…

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.

Re: Let's Destroy C

#172

Post by JabavuAdams »

I used to be really interested in new languages and compilers. Now ... let's just get on with making Machine Programmers / CASE tools. I don't want to be futzing around with individual lines of code anyway. I guess I want to be like a very technical PM.

Re: Let's Destroy C

#173

Post by tylerhou »

favorited wrote: post #163
juped wrote: post #142

Earlier quoted context omitted.

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).

And if all C users decided that, now that portability is much easier, it was time to define some of that behavior, it would happen. But, as much as people want to blame optimizing compilers for their behavior around UB, absolutely no one is going to sacrifice C's performance for safety.

Portability is still nontrivial. It’s still difficult to target all of x86, ARM, Power, RISC-V at once.

Re: Let's Destroy C

#174

Post by kccqzy »

shakna wrote: post #25
kccqzy wrote: post #10

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. C++ lambdas don't suffer from this problem.

GNU doesn't really have lambdas. This is an abuse of the compound statement macro. 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. gcc -fno-trampolines -I. examples/lambda.c Works. There's no tramp…

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.

Re: Let's Destroy C

#175

Post by rramadass »

Koshkin wrote: post #98

In some subtle way C was already "destroyed" with the introduction of C89. The K&R C had simplicity and beauty to it. Include files were small as they only contained the essential stuff (mostly definitions of structs). UNIX version 7 - the last "true" edition of UNIX - including its entire userspace - was still written in it. X Window system was written in it. Vi was written in it. Now all people do is complain.

>Now all people do is complain

Amen, brother! For a language that has been so supremely successful in the "real world", i simply don't understand the HN crowd's disdain for it.

As an aside, "printf format strings" are actually a DSL and hence the complexity. In their book, The Practice of Programming Kernighan & Pike actually show how to implement something similar for Network Packet encoding/decoding. It is quite neat and validates the power of this approach.

Re: Let's Destroy C

#176

Post by shakna »

kccqzy wrote: post #174
shakna wrote: post #25

Earlier quoted context omitted.

GNU doesn't really have lambdas. This is an abuse of the compound statement macro. 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. gcc -fno-trampolines -I. examples/lambda.c Works. There's no tramp…

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.

Re: Let's Destroy C

#177

Post by Dylan16807 »

ryandrake wrote: post #150
shakna wrote: post #71

Earlier quoted context omitted.

> 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.

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.

Re: Let's Destroy C

#178

Post by kaetemi »

ufo wrote: post #108
kaetemi wrote: post #38

Earlier quoted context omitted.

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.

True.

Re: Let's Destroy C

#179

Post by Dylan16807 »

lhweroiuwer wrote: post #129
dilippkumar wrote: post #117

I'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).

There are a lot of undefined behaviors that only exist out of inertia and laziness. For example there's a bunch of things that should be syntax errors that are instead UB.

> 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).

What's wrong with saying "it will either return an unspecified value or trap"?

Re: Let's Destroy C

#180

Post by hleach »

ebeip90 wrote: post #137
DougBTX wrote: post #93

Earlier quoted context omitted.

Agreed, if the attacker can modify string constants is, printf("Hello, World!\n"); really any safer than this? printf("%s\n", "Hello, World!");

No, they’re equivalent in terms of security. The article’s author (posting here on HN) is grossly mistaken.

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.

Post reply on HN