the c-semantics project is aimed against - C undefined behavior -

[legacy]

C provides just enough abstraction above assembly language for programmers to get their work done without having to worry about the details of the machines on which the programs run. Despite this abstraction, C is also known for the ease in which it allows programmers to write buggy programs. With no runtime checks and little static checking, in C the programmer is to be trusted entirely. Despite the abstraction, the language is still low-level enough that programmers can take advantage of assumptions about the underlying architecture. Trust in the programmer and the ability to write non-portable code are actually two of the design principles under which the C standard was written [14]. These ideas often work in concert to yield intricate, platform-dependent bugs. The potential subtlety of C bugs makes it an excellent candidate for formalization, as subtle bugs can often be caught only by more rigorous means.
...

To find out a solution the c-semantics project has been started as you can read from its - An Executable Formal Semantics of C with Applications - paper

What do you think about this project ? May be it is able to help us with C ?
See its git repo here (mind that this project is requiring dev-lang/ocaml)

[miguelvp]

Interesting but sometimes you want that odd behavior that you can achieve with C, so as long as you can define the behaviour you want, it will take features away instead of adding new features.

For example on the timer counting front, you want to be able to use current_time - previous_time and allow for roll over intentionally.

Also int really isn't defined and therefore it's not portable so checking for portability when you are targeting an 8bit MCU, or a 16bit MCU and a 32bit MCU then yeah, it will be nice if you didn't have to change the code but that comes at a price of using more code that you wouldn't need to.

That said, for some tasks, that looks great. If only it allow sections of the code to be ignored by the semantics rules and well defined by the user. Kind of a namespace that tells the kcc program to leave me alone I know what I'm doing.

[granz]

What do you think about this project ? May be it is able to help us with C ?
See its git repo here (mind that this project is requiring dev-lang/ocaml)

Valuable for proving that pure computational code is correct, but of little use for most firmware developers I would think (which I assume are the majority here).  If you are developing (or even just implementing) a complex algorithm in C it is very useful.  It doesn't help you with interacting with hardware peripheral registers on a particular microcontroller, for example.

[dannyf]

It is a mis-guided effort, in my view.

C is useful because it is flawed and imperfect.

[granz]

It is a mis-guided effort, in my view.

   Agreed.  Seems like it tries to force C to be something that it is not.

C is useful because it is flawed and imperfect.

Well, I'm not sure I would say "flawed," more like no-hand holding.

[Bored@Work]

Well, that project seems to start with some unproven assumption, the old claim that C is just a kind of better assembler and a similar old claim that it is easy to write buggy programs in C.

Since these claims are unproven there is actually no reason to read on. That c-semantics project looks awfully like yet another of those "I am too stupid to program, lets blame the language and invent a new vanity language" project. Next.

[tjaeger]

Well, that project seems to start with some unproven assumption, the old claim that C is just a kind of better assembler and a similar old claim that it is easy to write buggy programs in C.

Do you really not think it's easy to write buggy programs in C?  This is a truly strange claim.

Since these claims are unproven there is actually no reason to read on. That c-semantics project looks awfully like yet another of those "I am too stupid to program, lets blame the language and invent a new vanity language" project. Next.

Except that's the exact opposite of what they're doing.  As far as I understand, they're trying to formalize the C11 standard, and create a C compiler whose output can be trusted to produce object code in compliance with the spec.

[tjaeger]

It's always seemed strange to me that people see C as a language particularly well-suited to microcontroller development, rather than a flawed language that we ended up with for historical reasons that's just barely good enough for programmers (who are creatures of habit) to not seek alternatives.  Even some things that are trivial to code in assembler. like adding up two signed integers and checking for overflow, are next to impossible to do in C.

[miguelvp]

Except that's the exact opposite of what they're doing.  As far as I understand, they're trying to formalize the C11 standard, and create a C compiler whose output can be trusted to produce object code in compliance with the spec.

I should have read the paper more in detail, tjaeger seems to be right, I just scanned the doc until section 3.2 and it seemed to imply that

Code: [Select]

unsigned int a = 1000, b = 1000;
long int c = a * b;

should give you c = 1000000 but it really states that it's defined to be the value that fits in an unsigned int since it's not promoted to the type of the receiving variable. i.e. 0x000F4240 truncated to 16 bits 0x4240 so the result will be 16960.

So what they really are doing is to get the code to comply with the standard, not redefine the standard and they are focusing on C1X since it will overcome C99 as far as they are concerned.

[miguelvp]

It's always seemed strange to me that people see C as a language particularly well-suited to microcontroller development, rather than a flawed language that we ended up with for historical reasons that's just barely good enough for programmers (who are creatures of habit) to not seek alternatives.  Even some things that are trivial to code in assembler. like adding up two signed integers and checking for overflow, are next to impossible to do in C.

Agreed C is not well suited.
Disagree on programmers not seeking alternatives (they are just not present and no one is trying to make a high level mcu language)
Lastly C is flexible and will allow you to check for flags etc by using inline assembly and using macros to support different MCU's but that opens a can of worms in most environments because macros can be very dangerous if not understood.

Still C compilers are not that great to create assembler as most people tend to believe that optimizations write better code that the programmer doing it in assembler in the first place.

For example, MS Visual C doesn't even honor the register storage class specifier and MPLAB XC8 seems to abuse register 24, each instruction seems to use it as an intermediate step, making some code 5 times bigger or more. Seems it wants the PIC to just move stuff around more than actually doing work.

Can a new language be developed? yes, is someone doing it? we will see, will it become standard? probably not and it will fade away because it's not proven.

Only way a new language will have a chance is if a consortium of all the major MCU manufacturers did it and used it internally. Or even if one of the big players did it and adopted it, but that is risky so I doubt it will happen.

[hamster_nz]

Hands off my beloved language! :-)

I think C is a great language. It does just what you want, and nothing more. Sure there are some ragged edges, but it is the responsiblity of the programmer to unambiguiously say what they want.

If I was to code  "i = ++i + 1 " then I get all I deserve.

Also, they project can't have it both ways - you won't get no "C with no undefined bahaviour" if enabling optimizations can cause same code's output to be different (Yes, I'm looking at you, floating point!).

[legacy]

What i think ? The C language is like a carving knife: simple, sharp, and extremely useful in skilled hands, but like any sharp tool, C can injure people who don’t know how to handle it.

The problem is skilled hands, do not underestimate it, i have being still reading too much shit from the web about people who is supposing to be "skilled" when they are not.

[Jarrod Roberson]

I agree with the previous post that says the entire charter for this "project" is based on a flawed assumption.

C isn't any more responsible for bad programming than Intel is.

Most of the "complaints" I saw were not C specific but have more to do with the limitations of binary representation of numbers, which every language is going to have varying degrees of "correctness" of, of course offset by various tradeoffs of time and space considerations.

Blaming the language is blaming a tool because you picked the wrong tool doesn't make the tool to blame.

[dannyf]

My impression of their objectives is to make C harmless.

Unfortunately, a harmless tool is a useless tool.

[hans]

I've seen some talks about semantics before in regards of safety/security of programs written in C/C++. Most of that talk was targeted towards hacking programs, especially code vulnerabilities (as windows & data vulnerabilities are basically non-patchable..).

The overall conclusion was: C(++) is a very powerful language, but with a lot of responsibility to the programmer. The performance is available, and why it's still used. "Higher level" languages can't always reach the same level of performance, because they have more run-time checks which slows down programs, but does make it safer. In addition, JIT may add a bit of unpredictability in the mix as well.

The biggest drawbacks for C/C++ is these extra semantics add a huge performance hit. Especially those that require no modification to the code. For example, there is a semenatic that does a static call analysis, and has a list of possible return addresses of a method. When a hacker would modify the stack (which is possible, data vulnerability), it would be detected and the program won't continue (blindly) to the hackers code. It would be very effective, but slows stuff down a lot, and you need more than just a header file to do this for DLL's too.

Thus I believe there is no "solution" (as with everything in engineering). It's a trade off. You want the performance? Write C, make assumptions. Want securer programs? Write in a high level language, or with these semantics, or add the checks yourself manually in C (but it's easily overlooked what can go wrong or abused), but in all cases take the performance hit.

Mozilla is developing a new language "RUST", which relies on the LLVM compiler back end. So you can compile this for your ARM Cortex devices too, and people are already doing it. Maybe I will grab upon it one day and see what the benefits are; but the problem with a new language means yo have to port/rewrite/drop/respin legacy libraries, code and "ways of doing things". That's a huge time hit, plus you probably have to drop some platforms which will not keep up (like some stubborn manufacturers who have barely got a C compiler, like Microchip).

[granz]

It's always seemed strange to me that people see C as a language particularly well-suited to microcontroller development, rather than a flawed language that we ended up with for historical reasons that's just barely good enough for programmers (who are creatures of habit) to not seek alternatives.  Even some things that are trivial to code in assembler. like adding up two signed integers and checking for overflow, are next to impossible to do in C.

Microcontrollers vary widely.  How would you create a universally consistent language for microcontrollers anyhow?  C has several undefined behaviors to keep it from being tied to any particular architecture.  C allows inline asm to check platform dependent flags etc.

Many people have tried for a long time to come up with alternatives.  Interpreted languages such as Java or C# essentially solve all of the undefined behavior issues, but the price is paid for in performance.  On a PC when you are writing application software it's worth it, but on a Microcontroller you aren't writing portable code anyhow--you are very tied to the hardware anyway.

[Kjelt]

Yeah but you could abstract from the hardware by a HAL API you then get two worlds, all below the HAL would be C or asm and above whatever you want. Still it would cost quite some code which would add to the final product cost.
No if C is programmed by an experienced C programmer there are little worries, I think personally you get into bigger trouble by forcing that experienced C programmer to program a new higher level language (s)he is not familiar with.

[nctnico]

It is a mis-guided effort, in my view.

C is useful because it is flawed and imperfect.

The answer is already there: C++

[tjaeger]

It's always seemed strange to me that people see C as a language particularly well-suited to microcontroller development, rather than a flawed language that we ended up with for historical reasons that's just barely good enough for programmers (who are creatures of habit) to not seek alternatives.  Even some things that are trivial to code in assembler. like adding up two signed integers and checking for overflow, are next to impossible to do in C.

Microcontrollers vary widely.  How would you create a universally consistent language for microcontrollers anyhow?  C has several undefined behaviors to keep it from being tied to any particular architecture.  C allows inline asm to check platform dependent flags etc.

That's not really true.  C has implementation-defined behavior to cope with different architectures.  So for example when you cast a signed int to an unsigned int, you can get two's complement, one's complement or sign-absolute value depending on architecture. Undefined behavior is much more insidious and its rationale is to enable certain optimizations (if not outright mean-spiritedness).  So if you're implementing a binary heap and you realize that it costs less cycles to move between parent and children in 1-indexed arrays rather than 0-indexed arrays and you do things like

Code: [Select]

uint32_t a[16] = {0, };
uint32_t *heap = a-1;
you're might be in for a surprise depending on how aggressively your compiler optimizes.

Many people have tried for a long time to come up with alternatives.  Interpreted languages such as Java or C# essentially solve all of the undefined behavior issues, but the price is paid for in performance.  On a PC when you are writing application software it's worth it, but on a Microcontroller you aren't writing portable code anyhow--you are very tied to the hardware anyway.

It's the other way around.  Undefined behavior is a problem when you want to be tied to the hardware as closely as possible because the compiler is under no obligation to translate your code to what you would think it should correspond to.

[tjaeger]

It is a mis-guided effort, in my view.

C is useful because it is flawed and imperfect.

The answer is already there: C++

C++ has exactly the same issues with respect to undefined behavior as C.

[tjaeger]

My impression of their objectives is to make C harmless.

Unfortunately, a harmless tool is a useless tool.

You'd probably do well to familiarize yourself with their project before criticizing it for something that it's not.

[GiskardReventlov]

Has anyone tried kcc?  I have a seasick-like feeling when I hear about YAC (yet another compiler). Could they not fork an existing compiler in hopes of a future merge? Clang? Gcc? Have I missed the whole point?

Or is kcc a fork of gcc?

[grumpydoc]

The answer is already there: C++

But what was the question?

C is (or more accurately was) a fine language - just high level enough to be productive but low enough to get most system tasks done. The analogy to a sharp knife is a good one - you can cut yourself but only if you use the language without care or without a decent understaning of its nuances.

C++ - if we are keeping with the blade analogy - would be some sort of whirling dervish of a gadget with blades sticking out at all angles. Think of the Warner Brothers version of a Tasmanian devil crossed with Edward Scisorhands.

You can occasionally get some good results but you are almost certain to cut yourself somewhere.

Not that this has stopped me designing and writing some large projects in C++

[miguelvp]

The answer is already there: C++

C is (or more accurately was) a fine language ...

Definitely IS, if you think it's gone and/or replaced by C++ you are mistaken. Try to submit a kernel change in C++, or better yet, try to convince Linus Torvalds that C++ belongs in the kernel of linux.

I'll bring the popcorn for the rest of us

BTW I'm 100% with tjaeger, after I actually read the document they don't want to change the language, but they want to make a compiler that complies better with the specs.

Although they are not even close yet, it's a good effort, IMHO.

(edit: I guess I wasn't 100% with tjaeger, I read more and now I'm a naysayer)

[mtdoc]

I know nothing about C++ and am just learning C, but I found this plot interesting when presented in the embedded C online course I am taking