50 years of C, the good, the bad and the ugly [video] • Hacker News Board

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

#171

Post by pjmlp » Fri, Dec 30, 2022, 10:24 PM UTC

lelanthran wrote: post #135

KerrAvon wrote: post #81

Earlier quoted context omitted.

C has enough actual fans that I bet it never really goes away, but it won’t be useable in professional contexts after a while other than for maintenance, because people outside tech will start to call bullshit on the EULA liability shield.

> C has enough actual fans that I bet it never really goes away, but it won’t be useable in professional contexts after a while other than for maintenance, because people outside tech will start to call bullshit on the EULA liability shield. That's an extraordinary claim indeed; if people outside tech were going to call bullshit on EULAs as a liability shield, they would've done so in the last 50 years of software sa…

They already started with small steps.

- Return of goods in digital stores

- Warranties in consulting projects, requiring free of charge fixes up to one year

- Cybersecurity bills

It will only get better from now onwards.

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

#172

Post by pjmlp » Fri, Dec 30, 2022, 10:26 PM UTC

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…

WG14 never cared that much about security, as simple as that.

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

#173

Post by pjmlp » Fri, Dec 30, 2022, 10:30 PM UTC

andsoitis wrote: post #82

Speaker asks: "What can and should replace it?" (i.e. if you started a new project today, what language should you pick instead of C, because C would be the wrong choice). He goes on to list the following options (and says C++ does not count), but we'll only know far in the future which would have been the right pick: - Rust - Go - Zig - V - Nim - Swift - ...

The problem with C++, is that while it offers the language features to write safer code than C, it is also copy-paste compatible with C (most of it anyway).

So while a security conscious group can write C++ code that takes advantage of those features, other group can basically compile C++ code that is hardly any different from C.

So it is a better option than raw C, if it is the only viable alternative (like in HPC), but for security conscious scenarios one of the others is a better answer, if available.

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

#174

Post by hgs3 » Fri, Dec 30, 2022, 10:32 PM UTC

estebank wrote: post #145

hgs3 wrote: post #128

Earlier quoted context omitted.

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

A modern low level labguage would expose you to the concepts of cache lines and homogeneous and eterogeneous cores directly, with locality awareness to recognize false sharing. It would be something suitable to program the Cell architecture from PS2.

Those are fair points, but they're probably too specific to the architecture to incorporate in C's general execution model. They're better exposed through platform specific programming interfaces like OpenMP or CUDA. Even a domain specific language, like GLSL, may be more appropriate.

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

#175

Post by JonChesterfield » Fri, Dec 30, 2022, 10:34 PM UTC

Kototama wrote: post #94

JonChesterfield wrote: post #35

I maintain that C is fine and optimising compilers converting 'bad' C into dangerously broken binaries is not fine. We don't need to replace C to make it safe, we need to take the edge off undefined behaviour justified compiler rewrites.

Saying C is fine, does not make it fine though. The facts speak for themselves: even the best programmers in this world which are extremely conscious about security have vulnerabilities in the software they wrote because of C. There were two remotes vulnerabilities in OpenBSD since it's creation, more recently there was a vulnerability in the ping utility of FreeBSD, etc. C without undefined behaviors is not C anymor…

Strictly C where your implementation has provided sane definitions of undefined behaviour is still C. The implementation is free to provide definitions of undefined behaviour, and no diagnostic required doesn't mean no diagnostic permitted. Offhand I think all the undetectable parts are a quirk of separate compilation which is solvable by linking an IR instead of machine code. That would probably be a high value project to implement.

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

#176

Post by elcritch » Fri, Dec 30, 2022, 10:46 PM UTC

estebank wrote: post #146

elcritch wrote: post #71

Earlier quoted context omitted.

Unfortunately, Rust's core design philosophy is fundamentally opposed to much of the design philosophy that made C and C++ so popular and flexible. It's almost the exact opposite extreme on the pendulum, where C allowed anything while Rust limits to only what the language designers conceive as proper and not just safe. Zig can gain memory management systems like Nim's ARC which works well for system design and adds t…

What task can you do in C that you can't in Rust (or Zig, for that matter)?

No, I'd count Zig as having more of an "open ended" type system / philosophy.

Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `vec.insert(...)`.

The biggest ones for me in Rust is that it disallows extending traits for types you don't own, and the lack of function overloading. Neither of those are required for the borrow checker or safety, but it's a philosophical design decision.

1: https://github.com/ziglang/zig/issues/1251

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

#177

Post by tmtvl » Fri, Dec 30, 2022, 10:51 PM UTC

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…

Yeah, Ada is pretty great, it takes the best things from Pascal and combines it with unparalleled reliability.

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

#178

Post by kristoff_it » Fri, Dec 30, 2022, 10:55 PM UTC

elcritch wrote: post #176

estebank wrote: post #146

Earlier quoted context omitted.

What task can you do in C that you can't in Rust (or Zig, for that matter)?

No, I'd count Zig as having more of an "open ended" type system / philosophy. Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `…

> Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `vec.insert(...)`.

Zig doesn't have function overloading but it does have namespaced functions, so you can define your types and your "methods" on them.

https://ziglang.org/documentation/master/#struct

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

#179

Post by AndyKelley » Fri, Dec 30, 2022, 10:58 PM UTC

elcritch wrote: post #176

estebank wrote: post #146

Earlier quoted context omitted.

What task can you do in C that you can't in Rust (or Zig, for that matter)?

No, I'd count Zig as having more of an "open ended" type system / philosophy. Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `…

One of the main drawbacks of function overloading is that it can make code harder to read and understand. When the same function name is used for multiple different purposes, it is confusing for developers who are reading the code. This makes it more difficult to maintain and modify the code in the future, as developers spend extra time trying to understand the various function definitions and how they are being used. Even finding what file the function is in can be a non-trivial task.

Another issue with function overloading is that it can make code more difficult to debug. If a bug is found in one of the overloaded functions, it can be difficult to determine which function is causing the issue. This can make it more time-consuming to fix the bug and can lead to frustration for the developer. I remember debugging an issue at OkCupid and we lost many hours due to debug information being collapsed for overloads, making it look like the wrong function was being called in the debugger.

Finally, function overloading can lead to code that is more prone to errors. When the same function name is used for multiple different purposes, it can be easy to accidentally call the wrong function with the wrong arguments, which can lead to unintended consequences or runtime errors.

In conclusion, good riddance. This is what makes Zig a great language, that it doesn't have garbage like function overloading.

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

#180

Post by asveikau » Fri, Dec 30, 2022, 11:10 PM UTC

Koshkin wrote: post #167

asveikau wrote: post #153

Earlier quoted context omitted.

There are plenty of interesting C works out there, as well as data structures or algorithms that C can express elegantly. Small example, linked lists. I don't think non-C linked list code tends to be as straightforward as I've seen in C. Or the character-at-a-time style of string processing. It's kind of unique to C. You can say there is stuff about that you don't like. That's fine. Linked lists suck with modern CPU…

> as straightforward as I've seen in C To be fair, the most straightforward definition of the linked list is generic, and C completely lacks such facility. > fascist - Sounds familiar. https://news.ycombinator.com/item?id=33478321

> C completely lacks such facility.

Generic linked lists can be done with pointer casts. See the way the Linux kernel does it.

The list manipulation routine takes a pointer to a member, and the more specific type is opaque. The code that knows what the actual structure is can derive it from a node pointer.

A structure can even have multiple node pointers in this scheme.