Hacker News Reader

Comment by mannykannot | Hacker News Reader

C is frequently praised (including in some of the posts here) for its suitability for real-time and embedded systems development, but the author appears to be proposing modifying the C runtime and code generation in ways that, when done in other languages, are claimed to render them unsuitable for these purposes.

I think researchers are justified in looking for solutions for common problems, even if many C programmers will be uninterested in them, so I will not reject his proposals peremptorily.

View on HN

> C is frequently praised (including in some of the posts here) for its suitability for real-time and embedded systems development, but the author appears to be proposing modifying the C runtime and code generation in ways that, when done in other languages, are claimed to render them unsuitable for these purposes.

Don't people think there are things C could improve that wouldn't affect its suitability for these tasks? I mean getting namespaces doesn't strike me as being an hindrance for real-time systems for instance. A boolean type and true|false as keywords instead of macros? tagged unions? multiple return types to deal with errors more easily? more facilities in the language in general to avoid the use of macros to make up for its lack of polymorphism? to me macros always felt like a lazy cop-out.

Tagged unions? -- please no... I could be convinced to completely lose unions in C, though (pointer to member or base of struct can be cast to another struct anyway, so losing unions doesn't gain anything; for the same reason tagged unions just would not be useful)

Boolean type? Sure, but that would be dependent on use. What is wrong with a bitfield one bit wide instead? What may be useful is "packed bitfield" type ("packed" in Pascal). Then, array of packed bit could be expressed.

Multiple return types - yes, "return a b;" (or something would be nice.

Lack of polymorphism - reference "void *" The main problem is that calls cannot be constructed in C (that is, the standard does not have a "C to C" FFI.

Anyway, just food for thought.

Unions would be nice if the syntax for accessing substructure members could be nominally short circuited. For example:

struct ab { int a; int b; };

union c { struct ab ab_short_circuit; int a; };

union c c1; c1.a = 1; c1.b = 2;

That already exists, as a Microsoft extension, and if the struct is declared within the union, in standard C: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Unnamed-Fields....

(However, in your example, c1.a is ambiguous, so it won't compile.)

I did not realize this as a Linux user--thanks.

(But this is my point, it is should not be ambiguous.)

In fact, all of the things you propose are fairly simple. Leads one to wonder why C programmers haven't implemented these trivial things. Something about the C ecosystem seems to abhor standardization, modernization, and distribution. May have something to do with the kinds of people choosing to use C every day, despite the existence of an endless supply of potential replacements. I'm fairly sure the people who want all that stuff can already find it elsewhere, after all.

That is true for some things, though the preprocessor (which was not a "lazy cop-out" at the time) will be required for backwards compatibility. Some of the author's proposals, however, such as checked array access and garbage collection, would have runtime consequences.

Reply on news.ycombinator.com