Home » forums » LtU Forum

Proposal for a Friendly Dialect of C

Proposal for a Friendly Dialect of C
...We are not trying to fix the deficiencies of the C language nor making an argument for or against C. Rather, we are trying rescue the predictable little language that we all know is hiding within the C standard. This language generates tight code and doesn’t make you feel like the compiler is your enemy.
By Greg Buchholz at 2014-08-28 22:33 | LtU Forum | previous forum topic | next forum topic | other blogs | 6363 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The right kind of "friendly"

When I first saw the title, I was worried that by "friendly" they meant more approachable, easier to learn, etc.

Instead, this definition of "friendly" is much closer to the principle of least surprise. This is arguing for a dialect of C that does what you ask it to, rather than use each and every corner of the langauge spec as an excuse to punch you in the gut.

I still remember the first time a strict aliasing bug bit me, and I will never forget.

Even if nothing more comes of this proposal, it is good to make more people aware of the vast difference between "C" as defined in the specification, and the "C" that most systems programmers actually rely on to get things done.

By Tess Foley at Fri, 2014-08-29 16:52 | login or register to post comments

Follow-up

The Problem with Friendly C. Not surprising, even if it's a little disappointing.

By naasking at Sat, 2016-01-09 14:36 | login or register to post comments

CCured approach?

It seems like the "Friendly" and Boring C compilers would be amenable to the CCured approach and source-to-source transformation, but expanded to areas other than memory safety.

In this paper we propose a scheme that combines type inference and run-time checking to make existing C programs type safe. We describe the CCured type system, which extends that of C by separating pointer types according to their usage. This type system allows both pointers whose usage can be verified statically to be type safe, and pointers whose safety must be checked at run time. We prove a type soundness result and then we present a surprisingly simple type inference algorithm that is able to infer the appropriate pointer kinds for existing C programs. Our experience with the CCured system shows that the inference is very effective for many C programs, as it is able to infer that most or all of the pointers are statically verifiable to be type safe. The remaining pointers are instrumented with efficient run-time checks to ensure that they are used safely. The resulting performance loss due to run-time checks is 0–150%, which is several times better than comparable approaches that use only dynamic checking. Using CCured we have discovered programming bugs in established C programs such as several SPECINT95 benchmarks.

By Greg Buchholz at Fri, 2016-01-15 17:08 | login or register to post comments

bad optimizations.

the C/C++ compiler community has in the last few years reinterpreted the standard to allow them a few really bad optimizations because they're so greedy for bragging rights.

I'm actually offended that they came up with defensive names for unsafe optimizations that they pretend are safe because they interpret the standard as allowing them.

So unsafe pointer optimizations are "strict aliasing" because they're justified by strictly following the standard.

And unsafe arithmetic is "strict overflow" for the same excuse.

Every program written before they reinterpreted the rules that way is likely to have bugs unless you compile with -fno-strict-aliasing and -fno-strict-overflow.

It's not that compilers need to become boring, it's that committees who decide to go ahead with calling unsafe optimizations "safe" were always wrong.

By Josh Scholar at Thu, 2016-01-14 07:47 | login or register to post comments