Live data from Hacker News

C-for-all: Extending C with modern safety and productivity features

cforall.uwaterloo.ca

51–60 of 143 posts

Re: C-for-all: Extending C with modern safety and productivity features

#51
post #21
post #9

Does this have implications for low-level backdoors/exploits?

You mean like the Americans did with Cisco? I am not really in a mood to defend the chinese regime, but the “free” West really threw away any moral high ground we might have had.

You can't say "one is bad, therefore the other is good." They can both be bad.

Re: C-for-all: Extending C with modern safety and productivity features

#52

Obligatory name-drop: Zig is an awesome low level programming language targeting the same space as C and CForAll. It isn't at all compatible with C on the source level like CForAll is, but it does make it super easy to interop with C, because it can include .h files. That means it lets you move projects from C to Zig file-by-file. Because Zig benefits from decades of insights about how C could've been better, it has…

Zig is, however, unsuitable for interactive media or scientific computing due to the unfortunate lack of operator overloading (which is touted as a "feature"), rendering it less general purpose than I'd like.

Other aspects of its design look good however.

Re: C-for-all: Extending C with modern safety and productivity features

#53
post #27

Earlier quoted context omitted.

Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.

I'm yet to see a C++ project that compiles as fast as a C one.

groff does, but it restricts itself to C headers only.

Re: C-for-all: Extending C with modern safety and productivity features

#54
post #36

Earlier quoted context omitted.

> use MISRA-C MISRA-C's idea of safety is banning function pointers.

actually that's not true. It's more complicated than that[1]: --- Rule 104: This is there to prevent the address of a function from being calculated at run time. i.e. the use of pointer arithmetic to calculate the value of a pointer to function is prohibited. The reason is that an error in the calculation of the address could lead to a system failure. Rule 105: This is to ensure that a function pointer is only used t…

> you can improve readability by avoiding function pointers

How do you sort?

#include

void qsort(void base, size_t nmemb, size_t size, int (compar)(const void , const void ));

Re: C-for-all: Extending C with modern safety and productivity features

#55
Can we talk about the proposed new features:

How are tuples different from structs? You can pass around and return whole structs (not pointers) just fine in plain C.

Underscores in int literals should probably be proposed to the ISO committee for C itself. A similar concept works successfully in OCaml. (Binary literals would also be useful).

I've never felt that C lacked sufficient control structures, and the new ones proposed here just seem like they will confuse people. What specific problem is each new control feature trying to solve?

Adding exception handling (to C) seems like an actively bad idea. What are the semantics? How does unwinding work exactly and how would it interact with resource allocation?

Coroutines are today successfully handled in libraries, so I'm not sure what you gain by adding them to the language.

Re: C-for-all: Extending C with modern safety and productivity features

#57

if safety is what they want without departing from C just use MISRA-C > While C++, like C∀, takes an evolutionary approach to extending C, C++'s complex and interdependent features (e.g., overloading, object oriented, templates) mean idiomatic C++ code is difficult to use from C, and C programmers must expend significant effort learning C++. the "significant effort" for learning C++ pays off (financially), while this…

MISRA-C is just a set of rules. It does not stop humans making stupid mistakes or ignoring rules, and causing safety to be violated. It not as hard as rust where the binary is not built if a rule is violated.

Is it possible to check for compliance with MISRA-C rules programmatically?

If it is then it can be made part of the build process and the effect will be the same: the binary will not get built if the rules are violated.

Re: C-for-all: Extending C with modern safety and productivity features

#58
post #19
post #10

Earlier quoted context omitted.

So this is loading for you?

Yes, some of the many features : Tuples, left to right declaration syntax, references with auto dereferencing, constructors destructors, nested routines, extended case with ranges, choose (switch with no fallthrough), overloading and polymorphism.

Quite lot of that sounds like Turbo Pascal/Delphi.

Re: C-for-all: Extending C with modern safety and productivity features

#59
post #7

I'm sure a lot of very smart people are working on this, and I don't want to detract from their dedication, but man this language looks like a mess. And in no small part because it wants to be backwards compatible with C (the reasoning is unconvincing -- why not just use C++?). In the age of Go and Rust, which already have a hard time finding niches, I don't really think there's any room for a language like this. And…

It's very confusing, they start off saying C++ is too complicated and then go basically reinventing C++ with (IMO) absolutely awful syntax. I think they're missing the point of why people use C - there's no magic. It's pretty much the wysiwyg of high level -> asm. If you want a systems language with magic there's C++. If you want a safe one there's Rust. Personally if I were going to make C better, I'd add a better m…

> C - there's no magic

Strict aliasing and weak typing say hello.

> wysiwyg of high level -> asm

Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.

Re: C-for-all: Extending C with modern safety and productivity features

#60
Wow, this is quite a trainwreck. I think it's possible to improve C while keeping compatibility with C programs, but that's not how you should do it.

I think an improved C would be quite useful, but you really should be careful with what you include it, and keep the language simple. A lot of functionality feels like added because it could be added (WTF are nested routines). This way lies worse C++.

In particular, I wouldn't look too much into what C++ does. Rather, I would look into what Go, Rust and Zig do. `?{}` and `^?{}` are clearly inspired by C++ constructors and destructors, but that's not the only way (in fact, it's a rather bad approach if you want to keep things simple). For instance, you could avoid having constructors and require full initialization for structures with destructors. Hypothetically, it could look like this.

    struct Point {
        int x;
        int y;
    };

    struct Point new_point(int x, int y) {
        return { .x = x, .y = y };
    }

Meanwhile, C-for-all is mostly missing actually useful features. Slice types (https://www.drdobbs.com/architecture-and-design/cs-biggest-m...) would be huge, but they are nowhere to be seen. Vtable dynamic dispatch? Missing. Borrow checker? Missing. Module system (maybe a stretch, but...)? Missing.
Post reply on HN