Live data from Hacker News

Let's Destroy C

gist.github.com

121–130 of 192 posts

Re: Let's Destroy C

#121

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

[deleted]

Re: Let's Destroy C

#122
post #115

Earlier quoted context omitted.

How about just puts(“Hello, World!”) which has been in C since the dawn of time?

I think this is part of the problem with the language- a fragmented set of keywords, all with slightly different behavior.

puts and printf aren't keywords, they're regular functions.

Re: Let's Destroy C

#123

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

How about just puts(“Hello, World!”) which has been in C since the dawn of time?

GCC at least will compile a printf without special formatting characters as a pit, so it ends up being six of one in the end.

Re: Let's Destroy C

#124
post #60

Earlier quoted context omitted.

I see. So when for a char pointer one needs to do printf("%p\n", v); the Generic call must look like this displayln((const void *)v); is it really better?

Or you could have the pointer be a pointer before you feed it to the function. void* v; v = ...; ... displayln(v);

The amount of ellipsis shows that your solution is just as heavy weight.

Re: Let's Destroy C

#127

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…

Even a subset of that would be amazing to me -- "removed all of the undefined behaviors, added 128 bit signed and unsigned integers, features for explicit cache management (!!!), and container classes as part of a standard library"

Re: Let's Destroy C

#128
post #71
post #70

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

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?

Re: Let's Destroy C

#129

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

Post reply on HN