A nice blog post, about the Coverity scan not finding the Heartbleed (http://heartbleed.com/) bug:

http://blog.regehr.org/archives/1125

Bye,
bearophile

On Friday, 11 April 2014 at 09:47:14 UTC, bearophile wrote:
> A nice blog post, about the Coverity scan not finding the Heartbleed (http://heartbleed.com/) bug:
>
> http://blog.regehr.org/archives/1125
>
> Bye,
> bearophile

In a way it's scary how vulnerable software we rely on still is. I cannot claim that my software is immune to attacks, but where security is crucial, one would expect self-critical scrutiny rather than complacency. But we're all only human.

On 4/11/2014 2:47 AM, bearophile wrote:
> A nice blog post, about the Coverity scan not finding the Heartbleed
> (http://heartbleed.com/) bug:
>
> http://blog.regehr.org/archives/1125


http://www.reddit.com/r/programming/comments/22ri2i/heartbleed_wasnt_found_by_static_analysis/

On Friday, 11 April 2014 at 10:09:48 UTC, Walter Bright wrote:
> On 4/11/2014 2:47 AM, bearophile wrote:
>> A nice blog post, about the Coverity scan not finding the Heartbleed
>> (http://heartbleed.com/) bug:
>>
>> http://blog.regehr.org/archives/1125
>
>
> http://www.reddit.com/r/programming/comments/22ri2i/heartbleed_wasnt_found_by_static_analysis/

So why don't you just write your own language? Uh, wait, you did just that. Is there any chance that these issues will be fixed in C some day, or is it too late, or is the C consortium too narrow-minded, stubborn, indifferent?

On Friday, 11 April 2014 at 10:33:52 UTC, Chris wrote:
> On Friday, 11 April 2014 at 10:09:48 UTC, Walter Bright wrote:
>> On 4/11/2014 2:47 AM, bearophile wrote:
>>> A nice blog post, about the Coverity scan not finding the Heartbleed
>>> (http://heartbleed.com/) bug:
>>>
>>> http://blog.regehr.org/archives/1125
>>
>>
>> http://www.reddit.com/r/programming/comments/22ri2i/heartbleed_wasnt_found_by_static_analysis/
>
> So why don't you just write your own language? Uh, wait, you did just that. Is there any chance that these issues will be fixed in C some day, or is it too late, or is the C consortium too narrow-minded, stubborn, indifferent?

This will never change as we (me and Walter) discussed on a parallel thread.

The way arrays decay into pointers cannot be fixed while keeping backwards compatibility.

Algol, PL/I and Mesa had bounds checked arrays, with the option to disable them if required, but C designers decided against it.

The idea was that developers would use lint for such purposes, what very few do, even in 2014.

I am convinced that this will only get fixed by a generation change.

--
Paulo

Paulo Pinto:

> The idea was that developers would use lint for such purposes, what very few do, even in 2014.

Such moderate static analysis needs to be part of the default work of the language compiler.

Bye,
bearophile

Am 11.04.2014 16:00, schrieb bearophile:
> Paulo Pinto:
>
>> The idea was that developers would use lint for such purposes, what
>> very few do, even in 2014.
>
> Such moderate static analysis needs to be part of the default work of
> the language compiler.
>
> Bye,
> bearophile

Fully agree,
Paulo

On 4/11/2014 4:36 AM, Paulo Pinto wrote:
> This will never change as we (me and Walter) discussed on a parallel thread.
>
> The way arrays decay into pointers cannot be fixed while keeping backwards
> compatibility.
>
> Algol, PL/I and Mesa had bounds checked arrays, with the option to disable them
> if required, but C designers decided against it.
>
> The idea was that developers would use lint for such purposes, what very few do,
> even in 2014.
>
> I am convinced that this will only get fixed by a generation change.


The change I suggest is purely additive, meaning it will not break any existing code. If C can add VLAs, it can add this.

I have talked about this change with C people a few years ago, and I just kinda got a blank look in return. Maybe, though, C people will finally get fed up with these sorts of avoidable problems.

Walter Bright:

> Maybe, though, C people will finally get fed up with these
> sorts of avoidable problems.

Lot of the world computational infrastructure is based on C code,
so you can't just ignore their problems. If the C community is
not willing to improve, then people outside their culture have to
force them to change (because rewriting that code in another
language is often too much work).

Bye,
bearophile

On 4/11/2014 1:54 PM, bearophile wrote:
> Lot of the world computational infrastructure is based on C code,
> so you can't just ignore their problems. If the C community is
> not willing to improve, then people outside their culture have to
> force them to change (because rewriting that code in another
> language is often too much work).

That's why I offered a simple enhancement to C in the article.