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

50 years of C, the good, the bad and the ugly [video]

streaming.media.ccc.de

Post reply on HN
Print view View original

121–130 of 257 posts

Re: 50 years of C, the good, the bad and the ugly [video]

#121

Post by jeff-davis »

KerrAvon wrote: post #76
sirsinsalot wrote: post #34

Earlier quoted context omitted.

Anyone discouraging a particular tool without actual context of the problem being solved gets zero respect from me. It's a massive red flag that they don't know enough to be useful. C is great for the things C is great for, however small that range may or may not be now and in the future. Any other stance is reductive and misleading.

Exactly what, in the year 2023 C.E., is C great for? I’ve been writing C since 1991 and I can’t think of anything where I wouldn’t start a new project in some other language. There are many interesting choices of varying maturity in the low-level systems programming space: Zig, Rust, Crystal, D, Swift (if the standard library ever gains support for system-level programming). Even the “better C” subset of C++ will all…

The consequences of C in long-lived software are somewhat known. Granted, the track record of C is mixed, but many important projects have been successful with it.

Rust is exciting and proving itself about as rapidly as such a language could be expected to do. But there are big questions around how all of this plays out in a long-lived project. There's a good argument that C's simplicity is an asset here.

I like Rust a lot and have done some cool stuff with it. I believe the challenges of long-lived projects will be solved. But at the same time, I admit that there are a lot of other factors (including non-trchnical ones). If you pick a language that doesn't last for whatever reason, and you have a couple decades worth of code, the options are grim.

Re: 50 years of C, the good, the bad and the ugly [video]

#122

Post by titzer »

menaerus wrote: post #111
titzer wrote: post #108

Earlier quoted context omitted.

C would be a better language if it really lived up to its old ideal of being a "portable assembly language". That stopped being true as compilers started optimizing undefined behavior (e.g. signed overflow). Instead of a "+" in the source code yielding an honest-to-goodness hardware add instruction, it could be "optimized"--i.e. constant folded, CSE'd, strength-reduced, value-range-analyzed, among others--by an optim…

In the absence of CPU instruction which does the saturated ADD, how do you solve the overflow problem in a bare-metal language without introducing the performance hit?

It depends on how you define your language semantics. If you choose 2's complement wraparound semantics, which is what nearly all CPUs in the world have standardized on, there is nothing for the compiler to do. It's a pure operation, a single instruction, and can be constant-folded, strength-reduced, CSE'd, moved, dead-code-eliminated, etc. If you want a different semantics at the source level, e.g. overflow is an exception, then the compiler needs to emit additional code.

For Virgil I chose to settle on 2's complement because it's what hardware gives and has no overhead. It comes with the full compliment of fixed-width integers of widths 1-64 and odd-width ones come with zero-extension or sign-extension as necessary to make the underlying hardware width unobservable.

Re: 50 years of C, the good, the bad and the ugly [video]

#124

Post by menaerus »

Someone wrote: post #115
menaerus wrote: post #109

Earlier quoted context omitted.

Also without operator overloading, it wouldn't be possible to implement lazy evaluation, which along with the use of expression templates happens to be one of the most crucial aspects that any linear algebra library will want to take advantage of in order to generate the most optimal code.

> without operator overloading, it wouldn't be possible to implement lazy evaluation I don’t understand that. You can have functions that return promises that then can get passed to other functions returning promises, and leave it either to the compiler or to an expression evaluator you write (that ideally runs at compilation time as much as possible) to optimize away anything not needed. For example (pseudo-code) ve…

Of course, you can do it that way as well. However the problem with promise approach is that it is introducing extra dynamic memory allocations beneath and these cannot be optimized out or elided. At least, not to my knowledge. With expression templates and operator overloading you're basically avoiding exactly that as much as possible.

Re: 50 years of C, the good, the bad and the ugly [video]

#125

Post by thesuperbigfrog »

Someone wrote: post #116
sn41 wrote: post #61

Earlier quoted context omitted.

> that’s pretty much it. Only if you ignore 1. variadic arguments as in printf, 2. function pointers which are a very elementary (type-unsafe) form of closures, 3. a nice way of casting to void 4. setjmp and longjmp goodies (?) which allow you to code up co-routine libraries and exception handling mechanisms I'm sure there are more such facets I am missing. The elegance of the specification may be questionable, but t…

C is also relatively poor at providing “a way to define data structures which are really memory layouts”. Integer sizes (historically) and padding are implementation-defined, AFAIK bit fields are underspecified in that you cannot specify in what bits of a byte they end up.

So true.

I wish that C had a more rich way to define struct layouts and low-level representations for integral types.

I really like how Ada does it:

https://en.wikibooks.org/wiki/Ada_Programming/Representation...

If you need to read or write specialized hardware registers, being able to define a data structure with a custom representation is very nice and can save significant time and effort.

Re: 50 years of C, the good, the bad and the ugly [video]

#126

Post by fncslothouber »

ptx wrote: post #106
fncslothouber wrote: post #89

Earlier quoted context omitted.

Memory safety / security is important for a subset of all possible applications. It is not important for _all_ applications. If I use a micro controller to control a string of leds I do not care about security/memory safety. But I do care about being as close to the metal as possible, and being able to understand the compiled code.

If people rely on the LEDs working correctly or if the controller has any kind of connection to another system (which could be leveraged by an attacker to penetrate deeper into the network) it seems to me that security and memory safety would still be important.

Not everything is or needs to be connected to the Internet.

There are plenty of things that are controlled by a micro controllers that do not have a network connection.

Re: 50 years of C, the good, the bad and the ugly [video]

#127

Post by tialaramex »

titzer wrote: post #108
WastingMyTime89 wrote: post #52

Earlier quoted context omitted.

It’s mostly semantically very poor to be honest. C really is a nicer assembly in a lot of way. It’s extremely limited. You have branching logic, functions call, pointer arithmetic, a way to define data structures which are really memory layouts and that’s pretty much it. I guess you can appreciate that as an aesthetic statement but what you wrote would apply equally to any language with more complex semantics.

C would be a better language if it really lived up to its old ideal of being a "portable assembly language". That stopped being true as compilers started optimizing undefined behavior (e.g. signed overflow). Instead of a "+" in the source code yielding an honest-to-goodness hardware add instruction, it could be "optimized"--i.e. constant folded, CSE'd, strength-reduced, value-range-analyzed, among others--by an optim…

> if it really lived up to its old ideal of being a "portable assembly language".

What "old ideal" ? Where do you believe this "ideal" was expressed? Should I expect to find it in the First Edition K&R perhaps? Or in the documentation for the original C compiler? In the ANSI standard ?

C was never this mythical "portable assembly language" that's just something people say about it, mostly to ridicule it, you are engaging in Nostalgia.

Re: 50 years of C, the good, the bad and the ugly [video]

#128

Post by hgs3 »

Koshkin wrote: post #85
hgs3 wrote: post #28

Earlier quoted context omitted.

C is the best abstraction for many problem domains and that isn't going to change. I understand why folks coming from higher-level languages would dislike it, but for anyone coming from assembly it's a godsend. The speaker discourages C for new projects, but that says more about the problem domains they work in than C itself. C is what it is because the hardware and assembly language are what they are. Folks who want…

> C is the best abstraction for many problem domains It's really not, though. What C is an abstraction of is computer architecture as it existed by the late 1960s.

> It's really not, though. What C is an abstraction of is computer architecture as it existed by the late 1960s.

I don't follow. Barring micro-code, hardware is designed for executing either RISC or CISC instructions. If anything, the industry has matured and we see less esoteric ISA's today than in the 1960s.

Re: 50 years of C, the good, the bad and the ugly [video]

#129

Post by Sakos »

chillingeffect wrote: post #33
ImprobableTruth wrote: post #17

Earlier quoted context omitted.

They said a C-free build. For that you'd need to "just" rewrite the core kernel, which will be 150-200k lines, and the drivers + arch specific parts for one system. Still a tall order, but a decade isn't unrealistic if Rust proves itself. Now, rewriting everything , including all the legacy drivers? Yeah, never happening even if Rust succeeds utterly.

Once they get to that point, a new language will be available that makes up for the things Rust is still short on.

Maybe there's a case to be made for a multi-language kernel. Rust is the first step. Maybe it'll make sense at some point to keep Rust, but add another language.

Re: 50 years of C, the good, the bad and the ugly [video]

#130

Post by tails4e »

stephc_int13 wrote: post #65
tails4e wrote: post #57

I often wonder why c did not deprecate the bad bits, like the dodgy string functions should at least be behind a switch to enable, like --enable-strcat or something. Even the printf bug when passing a single argument is easily fixed by requiring two arguments at a minimum, etc. Then leveling up the std library to force the use of bounds checked strings and buffers, again hiding the unsafe ones behind switches or unsa…

The C language and the C stdlib are not the same things. You can use C without the stdlib. You simply have to build or use a different framework offering similar or better APIs.

Yes, of course. But making the stdlib more sane would dramatically improve things. Deprecating the dangerous methods and requiring unsafe keywords to use them coukd still be done
Post reply on HN