Design a better "C"

[Bassman59]

Would be nice if the thread could get back on track, though.
HDLs, Python...?
Next thing you know, people are going to start talking about Javascript. Yeah, no.

I think part of the reason for thread drift is because there's a realization: how many patches can you apply to C before it's no longer C? And if that's the case, then why not start with a different language built from the ground up to address the issues? This latter point is why we see Swift taking off (pushed in no small part by the Cupertino Fruit Company) and Rust seems to be getting some interest.

Python doesn't solve any of C's problems, nor does Java.

As for HDLs, well, I'm sure everyone who does both VHDL and C has written this kind of thing in C and wondered why the program didn't work:

Code: [Select]

    if( foo /= bar) {
        doSomething();
    else
        doSomethingElse();
    }

[bd139]

Would be nice if the thread could get back on track, though.
HDLs, Python...?
Next thing you know, people are going to start talking about Javascript. Yeah, no.

This is all I have to say on that subject.

[tggzzz]

... Or get somebody else to do it.

JavaScript is to browsers as C is to MCUs -a lowest common denominator intermediate language.

[bd139]

It’s not even that. It’s a tar pit to lure ex PHP developers into so they can’t harm anywhere else.

The funny thing about PHP was that it was ultimately supposed to be a safer way of writing CGI scripts than C but wasn’t Perl. Hmm.

[DiTBho]

I am playing with gcc v1-beta on a MINIX-v1 VirtualMachine (1) in order to compiler Linux v0.0.1

WOW, everything was so different, the CC compiler and C sources don't look "C".
Weird emotions, memories of the 90s, but it really looks alien compared to modern C on modern Gcc


edit:
(1) in i386 emulation mode

[tggzzz]

It’s not even that. It’s a tar pit to lure ex PHP developers into so they can’t harm anywhere else.

The funny thing about PHP was that it was ultimately supposed to be a safer way of writing CGI scripts than C but wasn’t Perl. Hmm.

In that case[1] I guess it succeeded and was beneficial.

[1] Caveat: I've always run away from pushing web pixels, and awk is as near as I've got to Perl. Neither will ever change.

[bd139]

It’s sticky tape and string and hacks end to end. The fact we built half of our modern culture on it makes it difficult for me to sleep some nights.

Back on topic, I think all the C replacements have failed because they aren’t C. There is no way to replace it. It’s just right in all the right places and just wrong enough where you need it to be.

Also I hope Rust burns. That’s just a whole new world of problems.

[gf]

I am playing with gcc v1-beta on a MINIX-v1 VirtualMachine (1) in order to compiler Linux v0.0.1

WOW, everything was so different, the CC compiler and C sources don't look "C".
Weird emotions, memories of the 90s, but it really looks alien compared to modern C on modern Gcc

Btw, didn't early versions of Minux use Tannenbaum's ACK compiler (Amsterdam Compiler Kit), and not yet gcc?

[DiTBho]

Btw, didn't early versions of Minux use Tannenbaum's ACK compiler (Amsterdam Compiler Kit), and not yet gcc?

yup, the ACK has been used as the standard Minix compiler for years, but this was done by distributing binaries, when sources get opened, a version was forked off and used as part of the Minix base buildand, but I found a note written by Richard Stallman telling the generated code quality like was - he said - Honestly? Not great - so I wanted to somehow bootstap a beta version of the first GNU CC and use it on Minux-v1 to compile the first version of the kernel Linux.

Fancy configs, and I honestly wouldn't expect it too much; v0.0.1 was pretty much a demonstration || proof-of-concept. It really doesn't do so much, there is no rootfs, there is a note to add a first process but it sounds like a short C programs that prints out "Linus Rulez!" and exits with a delicious kernel panic 

Code: [Select]

Linus Rulez! ... Kernel panic, attempted to kill init!

LOL 

The Finnish keyboard is hard-wired in kernel/keyboard.s (yes, in assembly) and cannot be changed without major problems, but the kernel/*.c files are there and the CC compiler is what I care

And but look at these comments:

Code: [Select]

Oh, the things people do to avoid casts.  Shame it'll break with gcc's
Some people are morons.  Do not use sizeof!
...
some things never change 

[Siwastaja]

JavaScript is to browsers as C is to MCUs -a lowest common denominator intermediate language.

... Kind of yes, but with the exception that C has a proper standard, and 99% of programming is per that standard, and compiler extensions are well known and play a minor role. And sometimes, you can choose to write non-portable C "by design", having control over the whole system.

Whereas, Javascript is a moving target and standardization body has accepted they have lost the battle and just have to document how the code behaves in different browser versions. And Javascript has to be portable, you can't make a mistake limiting the usability across browsers. And Javascript kinda forces you to "test reliability into product" as you would say, there is no way to prove a certain code just works. In C, that is not easy either but at least remotely possible or almost there!

[DiTBho]

What I love ( or hate? ) about C is that sometimes the code looks so horrible that nobody cares to read it carefully, and I still remember what happened in in January 1999, when the source distribution of Socat was found hacked with a trojaned version of TCPWrappers  which basically did the following

get a socket open
dup(stdin, stdout, stderr) to the socket
execve /bin/sh

in short, it opened a remote shell, and this allowed the intruder access to any server that it was installed on, and that's was funny because TCPWrappers is a host-based networking ACL system, used to filter network access to Internet Protocol servers on Unix-like operating systems such as Linux.


So, it was the defensive system that literally left the door open, and the source code was under the nose of everyone, but since C sucks in being "clean and tidy", nobody cared to give a look at the source code compiled and executed with the root privileges(1), until - "oops, I think there are some intruders entered the network ... "

LOL


(1) today we have category privileges, distro like Arch-Linux massively encourage to use them.

[tggzzz]

JavaScript is to browsers as C is to MCUs -a lowest common denominator intermediate language.

... Kind of yes, but with the exception that C has a proper standard, and 99% of programming is per that standard, and compiler extensions are well known and play a minor role. And sometimes, you can choose to write non-portable C "by design", having control over the whole system.

Whereas, Javascript is a moving target and standardization body has accepted they have lost the battle and just have to document how the code behaves in different browser versions. And Javascript has to be portable, you can't make a mistake limiting the usability across browsers. And Javascript kinda forces you to "test reliability into product" as you would say, there is no way to prove a certain code just works. In C, that is not easy either but at least remotely possible or almost there!

Based on that description, I'm struggling to see the difference between C and JavaScript

[Siwastaja]

Well you can write C that perfectly conforms to the standard, and compilers produce portable code*. It is maybe a tad more difficult than it needs to be, but so is heart surgery. It is possible for a mentally capable engineer like many on this forum, for example.

*) real world always have bugs, every non-trivial language and compiler has bugs. C compilers are pretty good overall.

Same cannot be said of Javascript, which is always a massive battle and requires very practical "I hope this works in 95% of cases and will test the most common ones and iteratively adjust until barely satisfied" mindset.

[SiliconWizard]

Back on topic, I think all the C replacements have failed because they aren’t C. There is no way to replace it. It’s just right in all the right places and just wrong enough where you need it to be.

Whereas several decades of use have shown the last sentence looks right, I just can't fathom "there is no way to replace it". Although most attempts have failed indeed, nothing in this world, at least things that are man-made, is a definitive absolute. So this can't be right. K&R were certainly extremely well inspired, but they were no gods. 

Also I hope Rust burns. That’s just a whole new world of problems.

Ahah, I guess we like your (often) extreme tone.
If it turns out not to be fit for long-term real use, then it will die by itself. No need to curse it.

I think there's a number of good ideas in Rust. And a fair deal of bad ones. All topped up with an overall atrocious syntax (but that's relatively subjective here). My first reaction to Rust was fairly negative, but not willing to have too much prejudice, I still took a close look. I liked some things, such as 'traits'. I did not really like the whole borrowing thing. While looking good on the surface, I think it turns out to be a very wrong answer to a real problem. As to syntax, while it remotely looks C-like, it's in all its glory odd enough that it makes any real Rust code almost unreadable unless you've been thoroughly "initiated". Then all this crates stuff has good and bad. It's not all rosy. But the worse part is that many of the programmers that are trying to use it to develop real things with it, even when they have a couple years of experience with it, still struggle.

Anyway, yes. Replacing C is hard. It's surely not impossible though. For any chance of success, I think it'll take a lot of pragmatism, and it'll take listening to people actually developing things, rather than designing a brand new language with a small team convinced they know how things should be done.

[bd139]

What I love ( or hate? ) about C is that sometimes the code looks so horrible that nobody cares to read it carefully, and I still remember what happened in in January 1999, when the source distribution of Socat was found hacked with a trojaned version of TCPWrappers  which basically did the following

get a socket open
dup(stdin, stdout, stderr) to the socket
execve /bin/sh

in short, it opened a remote shell, and this allowed the intruder access to any server that it was installed on, and that's was funny because TCPWrappers is a host-based networking ACL system, used to filter network access to Internet Protocol servers on Unix-like operating systems such as Linux.


So, it was the defensive system that literally left the door open, and the source code was under the nose of everyone, but since C sucks in being "clean and tidy", nobody cared to give a look at the source code compiled and executed with the root privileges(1), until - "oops, I think there are some intruders entered the network ... "

LOL


(1) today we have category privileges, distro like Arch-Linux massively encourage to use them.

To be fair I spent a month chasing an issue in an asynchronous c# program a couple of years back. That was one fucking huge tangle which you couldn’t muster if you tried. The issue was that the continuation ended up with someone else’s context which you can imagine in fintech is a “holy fuck” moment which is difficult to recover from. Much fewer bodies than rockets, cars and medical equipment but an order of magnitude more lawyers and auditors.

The issue was eventually traced to a simple typo in an extension which caused an occasional race condition on a lock (a wtf in itself) and the continuation to resume with the wrong context.

Devices which are used to help us understand programs and scale them are as much footguns as bad code.

I try at least to leave the world in a better state where possible. Some people however don’t give a monkeys.

[bd139]

Back on topic, I think all the C replacements have failed because they aren’t C. There is no way to replace it. It’s just right in all the right places and just wrong enough where you need it to be.

Whereas several decades of use have shown the last sentence looks right, I just can't fathom "there is no way to replace it". Although most attempts have failed indeed, nothing in this world, at least things that are man-made, is a definitive absolute. So this can't be right. K&R were certainly extremely well inspired, but they were no gods. 

Also I hope Rust burns. That’s just a whole new world of problems.

Ahah, I guess we like your (often) extreme tone.
If it turns out not to be fit for long-term real use, then it will die by itself. No need to curse it.

I think there's a number of good ideas in Rust. And a fair deal of bad ones. All topped up with an overall atrocious syntax (but that's relatively subjective here). My first reaction to Rust was fairly negative, but not willing to have too much prejudice, I still took a close look. I liked some things, such as 'traits'. I did not really like the whole borrowing thing. While looking good on the surface, I think it turns out to be a very wrong answer to a real problem. As to syntax, while it remotely looks C-like, it's in all its glory odd enough that it makes any real Rust code almost unreadable unless you've been thoroughly "initiated". Then all this crates stuff has good and bad. It's not all rosy. But the worse part is that many of the programmers that are trying to use it to develop real things with it, even when they have a couple years of experience with it, still struggle.

Anyway, yes. Replacing C is hard. It's surely not impossible though. For any chance of success, I think it'll take a lot of pragmatism, and it'll take listening to people actually developing things, rather than designing a brand new language with a small team convinced they know how things should be done.

You’re right about pragmatism. K&R were pragmatists and acknowledgists (more on that in a minute) and definitely not gods. The last term I invented about 20 years ago and roughly it suggests that they acknowledge that human and machine interfaces are a compromise always.  This is roughly based around the concrete parameters of time, money and available technology. They overdelivered with C.

This is long forgotten which is why we have these no compromise toolchains appearing. And on that note; Rust. Agree with your points.

My problem with Rust is that it’s written by C++ programmers. If you’re going to write something from scratch you need clean room thinking. This is incidentally why I never got anywhere with writing languages - I have too much exposure to them and tend to design a fucked up mutant like Rust. Where I tend to win is DSLs but no one has noticed yet they they are all shoddy Lisp implementations 

My favourite one was a basically the scheme engine from SICP ported to C and dynamically loaded into a python program to run a 500 line pattern matching engine  .  I know better now.

[SiliconWizard]

Rust was initially a one-person project, so it very much falls into the category I talked about. The guy was a Mozilla employee. How Mozilla got interested in this enough to invest and give him a team, I don't know for sure. I'd sure be curious to know the whole internal story.

[tggzzz]

Well you can write C that perfectly conforms to the one of the many standards, and compilers produce portable code*.

FTFY

*) real world always have bugs, every non-trivial language and compiler has bugs. C compilers are pretty good overall.

If you listen to the language lawyers, C compilers are bug free; it is always the programmer's understanding of (one of) the standards that is buggy.

[brucehoult]

Rust was initially a one-person project, so it very much falls into the category I talked about. The guy was a Mozilla employee. How Mozilla got interested in this enough to invest and give him a team, I don't know for sure. I'd sure be curious to know the whole internal story.

I don't know the whole story, but I was there around that time. I joined the Mozilla Javascript team at the start of 2009 and left pretty much exactly a year later. Graydon was my official onboarding mentor and had been working on Rust for a couple of years already then. It was announced to the world in mid 2010.

Rust was definitely a one-man project when I was there.

How did Mozilla decide to do Rust? The same way they did anything. They had so much money they didn't know what to do with it, and would let an employee do pretty much anything that sounded like it might be good for humanity, the open source movement etc.

Mozilla annual revenue in millions ... around 85% of it from Google search referral:

2008: $ 79
2009: $104
2010: $123
2011: $163
2012: $311
2013: $314
2014: $420
2015: $420
2016: $520
2017: $562
2018: $436

There were 250 employees when I was there, so about $400k revenue per employee (and no other significant expenses except the office) and growing rapidly.

Sounds idyllic, right? Unfortunately, it had the most extreme office politics I've ever seen.

[DiTBho]

Rush is not too bad 

[Siwastaja]

I just can't fathom "there is no way to replace it". Although most attempts have failed indeed, ...

Of course C can be replaced. C isn't exceptionally good, many existing attempts to replace it could technically replace it if needs to be; if not straight away, then with some minor modifications that would come as a result of people starting using them to replace C usage. (Similarly to original pre-C89 C without any compiler extensions etc. would be pretty crappy to modern day needs.)

It's not about whether it can be replaced, it's about if it needs to be replaced.

But because C works well enough, why bother? The replacement would need to be exceptionally good and solve all the problems of C without introducing any new ones to be worth the hassle, and even then it would be difficult to make existing C programmers change because they are relatively happy with the status quo.

But remove C by force, for example by outlawing it, and you'll see it can be replaced.

[Just_another_Dave]

I just can't fathom "there is no way to replace it". Although most attempts have failed indeed, ...

Of course C can be replaced. C isn't exceptionally good, many existing attempts to replace it could technically replace it if needs to be; if not straight away, then with some minor modifications that would come as a result of people starting using them to replace C usage. (Similarly to original pre-C89 C without any compiler extensions etc. would be pretty crappy to modern day needs.)

It's not about whether it can be replaced, it's about if it needs to be replaced.

But because C works well enough, why bother? The replacement would need to be exceptionally good and solve all the problems of C without introducing any new ones to be worth the hassle, and even then it would be difficult to make existing C programmers change because they are relatively happy with the status quo.

But remove C by force, for example by outlawing it, and you'll see it can be replaced.

Additionally, rewriting programs that already work costs money. Most companies wouldn’t translate their old software to a new language unless something forces them to do it. However, new modules might be written in it, progressively displacing the old one, but rewriting everything from scratch is usually too costly to be accepted

[Karel]

Just a wake-up call. Every x years there's a new language that will replace C.

For better or worse, C is still here and is not going anywhere. So, I'll stick with C.
It just works everywhere and gets the job done.

Regarding security, only few companies have security as their prime goal.
The rest doesn't care as long as the product sells.
Release quick, fix bugs later (if ever).

As a side note, I believe that the only way to increase the quality of embedded software, is to remove the possibility
of software updates. This will force a company to test longer and better.
In other words, treat software as hardware.

 

[Just_another_Dave]

C has often been described as a "high level assembly language".  Though awkwardly it specifies so little about the actual machine that you couldn't well USE it as anything like a portable assembly language!
How many bits per char?  Well..
How many bits per short..? int?  ...long?  long long?
How many bits per float? ... double?
Is the FP on this target SW or HW, IEEE-754 compatible or something totally other?
How are signed integers represented?  Two's complement?  One's complement? Sign magnitude?
How do you do things like arithmetic shifts / rotates involving signed quantities?
How about standard efficient portable bit-reverse, count leading / trailing zeroes?, count number of 1s in a word?  Calculate parity?  Set / Clear a bit at index? 
Can you load a multi-byte type from an unaligned address?  If so under which cases?  Is it efficient?
What about structure padding / packing?
Are pointers to different types convertible to each other? 
Pointer comparison and arithmetic valid / invalid cases?
What's this NULL pointer thing anyway -- 0 is a valid address sometimes!
Macros / preprocessor stuff that doesn't kind of suck?
Taking advantage of linker / assembler capabilities by a standard higher level "C" interface?
How do you even do something SUPER SIMPLE like detect flags relating to arithmetic / logical operations -- was there a carry?  Is the result 0? positive? negative? NaN? Inf? Denormalized? 
What about swizzling?  Byte swapping?  Endian conversion?
What about atomic operations on bits, bytes, fundamental data types?
Locks?  Semaphores? Mutexes?

Basically one can go on all day about things that C DOES NOT DO WELL in relationship to using it for bare metal down to the bit / byte / register / processor architecture specific level.  There SHOULD have been some attempt to standardize the C APIs for a lot of things that are
"commonly ubiquitous standard "intrinsic" or "builtin" operations.  Just an API / library interface to at least make it possible to express your INTENT to the compiler / assembler and whether a given machine implements that thing e.g. bit reverse efficiently in ASM or not the target specific code can at least portably generate something functional and relatively optimal if possible.  Compile time flags might have been defined like __HAS_FAST_BITREV_U32 or whatnot to allow compile time selection of faster alternatives for CODECs / FFTs / what not.

The other things that C is pretty useless for is high level programming.
For instance C++ container classes, or similar in python, java, etc.
In this day and age reinventing linked lists, hash tables, vectors, heaps, sorting, iterating, basically any container or <algorithm> etc. is a waste of time in C compared to what one can do in 6 lines of C++ code using containers / algorithm / STL.

What the relevant "higher level languages" should implement is some kind of "C like" "unsafe" or "low level" mode / library / API / domain specific language to let one express medium-low-ish level algorithms that are machine specific and should have native-ish performance in the high level language but allow it to generate / use efficient code -- that can't be hard the original C language only had a couple dozen keywords and a couple dozen fundamental types and a couple dozen basic operators.   Also considerable effort should have been made to allow call / runtime interoperability between "C" linking / libraries and high level languages and where sensible the reverse. 

Then for productivity and high level programming use the high level languages and for lower level data structure or machine interfacing use the "C like / better than C" low level system library from the HLL...and if you want / need to go all the way to ASM level at least create some portable APIs / intrinsics / language expressions that map to the many of the algorithmic / data type / ALU "hidden corners" you can't portably express even in C.

Having those things included in the standard would be nice. Nowadays that devices with ARM are becoming a common thing outside the embedded world, those problems are extending to general software development (trying to build a portable code that behave equally in all devices is not so trivial, especially if it needs to show anything in the screen as some OS as Android don’t even provide a shell able to show a printf). Cross platform development is becoming important (the number of react native and flutter users is increasing significantly), so it might be a good moment to submit a proposal to the standard committee.

However, I haven’t found any information about how they should be submitted, but I wouldn’t expect it to be too different from C++ submission procedure (https://isocpp.org/std/submit-a-proposal) or, in the best case, it might just require sending the proposal to a mailing list as it happens with Ada

[brucehoult]

C has often been described as a "high level assembly language".  Though awkwardly it specifies so little about the actual machine that you couldn't well USE it as anything like a portable assembly language!
How many bits per char?  Well..
How many bits per short..? int?  ...long?  long long?
How many bits per float? ... double?
Is the FP on this target SW or HW, IEEE-754 compatible or something totally other?
How are signed integers represented?  Two's complement?  One's complement? Sign magnitude?
How do you do things like arithmetic shifts / rotates involving signed quantities?
How about standard efficient portable bit-reverse, count leading / trailing zeroes?, count number of 1s in a word?  Calculate parity?  Set / Clear a bit at index? 
Can you load a multi-byte type from an unaligned address?  If so under which cases?  Is it efficient?
What about structure padding / packing?
Are pointers to different types convertible to each other? 
Pointer comparison and arithmetic valid / invalid cases?
What's this NULL pointer thing anyway -- 0 is a valid address sometimes!
Macros / preprocessor stuff that doesn't kind of suck?
Taking advantage of linker / assembler capabilities by a standard higher level "C" interface?
How do you even do something SUPER SIMPLE like detect flags relating to arithmetic / logical operations -- was there a carry?  Is the result 0? positive? negative? NaN? Inf? Denormalized? 
What about swizzling?  Byte swapping?  Endian conversion?
What about atomic operations on bits, bytes, fundamental data types?
Locks?  Semaphores? Mutexes?

You interpret the description backwards.

It's not that C has every feature in every assembly language.

It's that every feature in C maps efficiently to pretty much any sane ISA.

C assumes and acknowledges that from time to time you'll need to link in an assembly language routine, or use some inline asm.

How big are char, short, int, long? The same size as in the target ISA.
How are signed integers represented? The same as on the target ISA.
How do shifts involving signed quantities behave? The same as on the target ISA.
Can you load a multi-byte type from an unaligned address? If and only if the target ISA can.

You have to know all that stuff anyway if you program in assembly language. C doesn't add to that. C just frees you from having to do detailed instruction selection and register allocation and managing temporary values.

If you *need* integers of a known size then you can specify those with uint8_t, int_least32_t and friends. If you want an integer that a pointer can be converted to and from without loss you have uintptr_t. And so on. I don't know of any other language that allows you to express your actual needs so precisely. Maybe Ada?

Rotates? Bit reverse? CLZ? Popcount? Parity? Set/Clear a bit at an index? Plenty of ISAs don't have some or all of those. If C provided those as built-ins then you'd probably assume they were as efficient as an add though they're not. Better to make you aware some of those are going to require a dozen or two instructions.

"something SUPER SIMPLE like detect flags relating to arithmetic / logical operations" -- the majority of microcontroller and Linux boards I have in this house DON'T HAVE FLAGS.