> 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.
Let's Destroy C
121–130 of 192 posts
Re: Let's Destroy C
#122Earlier 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.
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?
Re: Let's Destroy C
#124Earlier 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);
Re: Let's Destroy C
#125Re: Let's Destroy C
#126Re: Let's Destroy C
#127I'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…
Re: Let's Destroy C
#128Earlier 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.
Re: Let's Destroy C
#129I'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…
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).