Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #4711 > unrolled thread

Research to Create Automated Buffer Overflow Protection

Back to article view | Back to comp.programming

Contents

  Research to Create Automated Buffer Overflow Protection Heidi Brayer <hap1026@gmail.com> - 2014-08-26 09:11 -0700
    Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 18:54 +0200
      Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-26 18:16 +0100
        Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 19:35 +0200
          Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-26 18:59 +0100
            Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 21:26 +0200
              Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-26 20:33 +0100
                Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 21:50 +0200
                  Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-26 21:41 +0100
                    Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 10:21 +0200
                      Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-27 10:27 +0100
                        Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 11:51 +0200
          Re: Research to Create Automated Buffer Overflow Protection Melzzzzz <mel@zzzzz.invalid> - 2014-08-26 20:39 +0200
            Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-26 20:13 +0100
            Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-26 21:38 +0200
              Re: Research to Create Automated Buffer Overflow Protection Melzzzzz <mel@zzzzz.com> - 2014-08-26 23:11 +0200
                Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 09:50 +0200
                  Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-27 10:16 +0100
                    Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 12:15 +0200
                    Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-08-27 14:40 +0100
              Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-27 10:13 +0100
                Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 14:06 +0200
              Re: Research to Create Automated Buffer Overflow Protection "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-27 10:32 +0100
                Re: Research to Create Automated Buffer Overflow Protection "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-08-27 12:14 +0200
          Re: Research to Create Automated Buffer Overflow Protection "Chris M. Thomasson" <no@spam.invalid> - 2014-08-26 14:06 -0700
        Re: Research to Create Automated Buffer Overflow Protection Melzzzzz <mel@zzzzz.invalid> - 2014-08-26 20:16 +0200
          Re: Research to Create Automated Buffer Overflow Protection Öö Tiib <ootiib@hot.ee> - 2014-08-30 09:20 -0700
    Re: Research to Create Automated Buffer Overflow Protection Jongware <jongware@no-spam.plz> - 2014-09-15 10:47 +0200
      Re: Research to Create Automated Buffer Overflow Protection Richard Heathfield <invalid@see.sig.invalid> - 2014-09-15 10:46 +0100

Page 1 of 2  [1] 2  Next page →

#4711 — Research to Create Automated Buffer Overflow Protection

According to a 2013 report examining 25 years of vulnerabilities (from 1998 to 2012), buffer overflow causes 14 percent of software security vulnerabilities and 35 percent of critical vulnerabilities, making it the leading cause of software security vulnerabilities overall. As of July 2014, the TIOBE index indicates that the C programming language, which is the language most commonly associated with buffer overflows, is the most popular language with 17.1 percent of the market. Embedded systems, network stacks, networked applications, and high-performance computing rely heavily upon C. Embedded systems can be especially vulnerable to buffer overflows because many of them lack hardware memory management units. This blog post describes my research on the Secure Coding Initiative in the CERT Division of the Carnegie Mellon University Software Engineering Institute to create automated buffer overflow prevention.

To read more, please follow this link
http://blog.sei.cmu.edu/post.cfm/performance-compiler-assisted-memory-safety-checking-237. 

[toc] | [next] | [standalone]

#4712

On Tue, 26 Aug 2014 09:11:35 -0700 (PDT), Heidi Brayer wrote:

> According to a 2013 report examining 25 years of vulnerabilities (from
> 1998 to 2012), buffer overflow causes 14 percent of software security
> vulnerabilities and 35 percent of critical vulnerabilities, making it the
> leading cause of software security vulnerabilities overall. As of July
> 2014, the TIOBE index indicates that the C programming language, which is
> the language most commonly associated with buffer overflows, is the most
> popular language with 17.1 percent of the market. Embedded systems,
> network stacks, networked applications, and high-performance computing
> rely heavily upon C. Embedded systems can be especially vulnerable to
> buffer overflows because many of them lack hardware memory management
> units. This blog post describes my research on the Secure Coding
> Initiative in the CERT Division of the Carnegie Mellon University Software
> Engineering Institute to create automated buffer overflow prevention.
> 
> To read more, please follow this link
> http://blog.sei.cmu.edu/post.cfm/performance-compiler-assisted-memory-safety-checking-237.

Would be much more helpful if they researched how to get rid of C, or at
least, stopped teach students crappy languages and idiotic SW design
techniques.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4713

Dmitry A. Kazakov wrote:

> On Tue, 26 Aug 2014 09:11:35 -0700 (PDT), Heidi Brayer wrote:
>

<snip>

>> This blog post describes my research on the Secure Coding
>> Initiative in the CERT Division of the Carnegie Mellon University
>> Software Engineering Institute to create automated buffer overflow
>> prevention.
>> 
>> To read more, please follow this link
>> http://blog.sei.cmu.edu/post.cfm/performance-compiler-assisted-memory-
safety-checking-237.
> 
> Would be much more helpful if they researched how to get rid of C, or at
> least, stopped teach students crappy languages and idiotic SW design
> techniques.

The problem is that C is popular even now because it is such a powerful 
language. You can't eliminate stupidity, but by reducing the scope for doing 
stupid things you also reduce the scope for doing clever things. Few people 
like to think of themselves as stupid (whatever the true facts of the 
matter), so they get this idea that they can avoid C's pitfalls whilst 
taking advantage of its power. And some of them, at least, are right.

The only ways to get rid of C, in decreasing order of severity are:

(a) catastrophic global war, pestilence, or famine;
(b) legislation of an alarmingly authoritarian nature;
(c) the provision of an even more powerful language that is even more prone 
to being abused.

If you add bounds-checking to C (which is what we're talking about, really), 
(a) you discover eventually that people have already done it, and (b) 
bounds-checking imposes a performance penalty that at least some people are 
not prepared to tolerate.

Note, too, that even if you consider C to be a "crappy language", that 
doesn't mean that the rest of the world agrees with you. Some consider C to 
be a powerful tool for writing fast programs. Powerful tools often have 
sharp edges. If you cut yourself, that doesn't mean the tool is crappy. It 
may just mean you don't know how to use the tool properly. And filing down 
the edges may leave you without any appropriate tool to use in a particular 
situation.

If you want Ada, you know where to find it.
 
-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#4714

On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:

> The only ways to get rid of C, in decreasing order of severity are:
> 
> (a) catastrophic global war, pestilence, or famine;
> (b) legislation of an alarmingly authoritarian nature;
> (c) the provision of an even more powerful language that is even more prone 
> to being abused.

(d) liability to the damages caused by software faults.

> (b) 
> bounds-checking imposes a performance penalty that at least some people are 
> not prepared to tolerate.

The necessity of bounds-checking is greatly overestimated. There is no need
to check for the bounds if the language constructs prevent indices or
iterators going out of the bounds. C lacks such constructs, e.g. safe
looping over the elements of a container or array. In many if not most of
the cases this does not involve any explicit index at all and if it does,
the index is guaranteed within the bounds. Such primitives would offer a
better performance over crude C's pointer arithmetic as well. 

> If you want Ada, you know where to find it.

I do.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4715

Dmitry A. Kazakov wrote:

> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
> 
>> The only ways to get rid of C, in decreasing order of severity are:
>> 
>> (a) catastrophic global war, pestilence, or famine;
>> (b) legislation of an alarmingly authoritarian nature;
>> (c) the provision of an even more powerful language that is even more
>> prone to being abused.
> 
> (d) liability to the damages caused by software faults.

Like (a) above, that would take out ALL programming languages, not just C.

>> (b)
>> bounds-checking imposes a performance penalty that at least some people
>> are not prepared to tolerate.
> 
> The necessity of bounds-checking is greatly overestimated.

Precisely my point.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#4719

On Tue, 26 Aug 2014 18:59:49 +0100, Richard Heathfield wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>> 
>>> The only ways to get rid of C, in decreasing order of severity are:
>>> 
>>> (a) catastrophic global war, pestilence, or famine;
>>> (b) legislation of an alarmingly authoritarian nature;
>>> (c) the provision of an even more powerful language that is even more
>>> prone to being abused.
>> 
>> (d) liability to the damages caused by software faults.
> 
> Like (a) above, that would take out ALL programming languages, not just C.

I don't see anything catastrophic in that. Just making the software market
working. Yes it could take out languages promoting software quality as an
expense.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4720

Dmitry A. Kazakov wrote:

> On Tue, 26 Aug 2014 18:59:49 +0100, Richard Heathfield wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>>> 
>>>> The only ways to get rid of C, in decreasing order of severity are:
>>>> 
>>>> (a) catastrophic global war, pestilence, or famine;
>>>> (b) legislation of an alarmingly authoritarian nature;
>>>> (c) the provision of an even more powerful language that is even more
>>>> prone to being abused.
>>> 
>>> (d) liability to the damages caused by software faults.
>> 
>> Like (a) above, that would take out ALL programming languages, not just
>> C.
> 
> I don't see anything catastrophic in that.

If I take you at your word, you don't see anything catastrophic about the 
collapse of the software world as we know it.

> Just making the software market
> working. Yes it could take out languages promoting software quality as an
> expense.

If people were made liable for damages inflicted by their broken software, 
the hike in their insurance premiums would make it uneconomic to produce any 
software at all. This would destroy not only C, but also Ada, C#, SmallTalk, 
Lithp, Ruby, Haskell... the lot. Nobody would write programs any more. This 
would of course have the advantage that no new buffer overrun problems would 
be created.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#4722

On Tue, 26 Aug 2014 20:33:03 +0100, Richard Heathfield wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Tue, 26 Aug 2014 18:59:49 +0100, Richard Heathfield wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>> 
>>>> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>>>> 
>>>>> The only ways to get rid of C, in decreasing order of severity are:
>>>>> 
>>>>> (a) catastrophic global war, pestilence, or famine;
>>>>> (b) legislation of an alarmingly authoritarian nature;
>>>>> (c) the provision of an even more powerful language that is even more
>>>>> prone to being abused.
>>>> 
>>>> (d) liability to the damages caused by software faults.
>>> 
>>> Like (a) above, that would take out ALL programming languages, not just
>>> C.
>> 
>> I don't see anything catastrophic in that.
> 
> If I take you at your word, you don't see anything catastrophic about the 
> collapse of the software world as we know it.

It collapsed already.

>> Just making the software market
>> working. Yes it could take out languages promoting software quality as an
>> expense.
> 
> If people were made liable for damages inflicted by their broken software, 
> the hike in their insurance premiums would make it uneconomic to produce any 
> software at all.

No. It would make software prices to reflect the reality. Software is a
very expensive thing. At the same time 80% of all software produced is just
garbage nobody really needs. Do you need Windows start button appearing and
disappearing? It is not sustainable. This happens only because others are
paying against their will. There cannot be anything worse than this.

> This would destroy not only C, but also Ada, C#, SmallTalk, 
> Lithp, Ruby, Haskell... the lot. Nobody would write programs any more.

This cannot happen at a functioning market. Where there is a demand there
will be an offer.

If there is no demand, no need to waste CPU cycles and human lives
producing useless garbage.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4723

Dmitry A. Kazakov wrote:

> On Tue, 26 Aug 2014 20:33:03 +0100, Richard Heathfield wrote:
> 
<snip>

>> If people were made liable for damages inflicted by their broken
>> software, the hike in their insurance premiums would make it uneconomic
>> to produce any software at all.
> 
> No. It would make software prices to reflect the reality. Software is a
> very expensive thing.

That's actually a very good response, so I'll do my best to meet like with 
like.

If people are going to pay even more for their software than they do now, 
then they're going to want it to run like stink, in which case the 
developers are going to at least consider using C. Software quality is about 
freedom from fault, but it is *also* about performance. We cannot ignore 
performance.

The difference would be that only the best programmers would get hired 
(because there would be stiffer competition for the fewer available jobs 
that would result from less software being written). And the best 
programmers would develop strategies that allowed them to ensure freedom 
from fault whilst still taking advantage of the performance benefits of a 
low-level language.

> At the same time 80% of all software produced is
> just garbage nobody really needs. Do you need Windows

No. :-)

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#4728

On Tue, 26 Aug 2014 21:41:48 +0100, Richard Heathfield wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Tue, 26 Aug 2014 20:33:03 +0100, Richard Heathfield wrote:
>> 
> <snip>
> 
>>> If people were made liable for damages inflicted by their broken
>>> software, the hike in their insurance premiums would make it uneconomic
>>> to produce any software at all.
>> 
>> No. It would make software prices to reflect the reality. Software is a
>> very expensive thing.
> 
> That's actually a very good response, so I'll do my best to meet like with 
> like.
> 
> If people are going to pay even more for their software than they do now, 
> then they're going to want it to run like stink, in which case the 
> developers are going to at least consider using C. Software quality is about 
> freedom from fault, but it is *also* about performance. We cannot ignore 
> performance.
> 
> The difference would be that only the best programmers would get hired 
> (because there would be stiffer competition for the fewer available jobs 
> that would result from less software being written). And the best 
> programmers would develop strategies that allowed them to ensure freedom 
> from fault whilst still taking advantage of the performance benefits of a 
> low-level language.

Even best of the best programmers cannot improve quality of C code beyond
certain (quite low) level.

The problem is that you consider programming as a kind of art, so the idea
is basically achieving whatever goals by fixing people (programmers) rather
than tools (languages). You cannot ensure any properties dealing with arts.
It is a dead end.

Programming must become an engineering. In an engineering discipline you
can evaluate risks and expenses, have realistic schedules, and, yes,
minimize the human factor making us, pride programmers, replaceable
technicians.

Programming will never become engineering with languages like C. Which is
one of multiple reasons why programmers defend C being aware of all its
deficiencies, in unconscious self-defence.

Low-level vs. high-level plays little role. Arguably C is not a low-level
language as it became quite remote from the modern hardware, which is a way
distant from PDP machines. The question is handling complexity of the
software being developed, early error detection (static checks etc). C is
extremely poor with all that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4731

Dmitry A. Kazakov wrote:

> Even best of the best programmers cannot improve quality of C code beyond
> certain (quite low) level.

Dan Berstein ?  More generally, I don't think there's an upper limit to code 
quality in any language (except in the trivial sense), and that includes C.


> The problem is that you consider programming as a kind of art, so the idea
> is basically achieving whatever goals by fixing people (programmers)
> rather than tools (languages). You cannot ensure any properties dealing
> with arts. It is a dead end.

I suspect it always will be a kind of art.

Reasons:

1) because anything aspect of a activity that can be turned into "engineering" 
can -- by definition -- be automated.

2) the complexity wall (as I've heard it called) -- programming is /only/ 
limited by our ability to manage the compexity of what we do, so -- no matter 
what tools or techniques we use to decrease the complexity (including 
engineering discipline) -- we will always use up the advantage gained thereby 
in attempting even more complex programming tasks.


> Programming will never become engineering with languages like C.

FWIW, the nearest I've heard of to programming as "engineering" (at least some 
aspects of that concept) have used C.  Probably because with C the need for 
iron discipline is most apparent, and the gains from it (if any) are also most 
apparent.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#4733

On Wed, 27 Aug 2014 10:27:40 +0100, Chris Uppal wrote:

> Dmitry A. Kazakov wrote:
> 
>> Even best of the best programmers cannot improve quality of C code beyond
>> certain (quite low) level.
> 
> Dan Berstein ?  More generally, I don't think there's an upper limit to code 
> quality in any language (except in the trivial sense), and that includes C.
> 
> 
>> The problem is that you consider programming as a kind of art, so the idea
>> is basically achieving whatever goals by fixing people (programmers)
>> rather than tools (languages). You cannot ensure any properties dealing
>> with arts. It is a dead end.
> 
> I suspect it always will be a kind of art.
> 
> Reasons:
> 
> 1) because anything aspect of a activity that can be turned into "engineering" 
> can -- by definition -- be automated.

Engineering is a human activity (of applying the corresponding science). As
such it cannot be automated. IMO, it is rather:

machine/process (automated)
    /      \
artisan   technician/engineer (average person)
  /          \
artist     scientist (unique person)
   \         /
    no way

> 2) the complexity wall (as I've heard it called) -- programming is /only/ 
> limited by our ability to manage the compexity of what we do, so -- no matter 
> what tools or techniques we use to decrease the complexity (including 
> engineering discipline) -- we will always use up the advantage gained thereby 
> in attempting even more complex programming tasks.

Building spaceships is maybe an art, but building cars is a solid
engineering. It think there is much space within the borders of what is
economically infeasible (now) and what is fundamentally impossible (ever).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4717

On Tue, 26 Aug 2014 19:35:26 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
> 
> > The only ways to get rid of C, in decreasing order of severity are:
> > 
> > (a) catastrophic global war, pestilence, or famine;
> > (b) legislation of an alarmingly authoritarian nature;
> > (c) the provision of an even more powerful language that is even
> > more prone to being abused.
> 
> (d) liability to the damages caused by software faults.

Bad programmers write bad programs in any language. There is no
such language that protects from software faults...


> 
> > (b) 
> > bounds-checking imposes a performance penalty that at least some
> > people are not prepared to tolerate.
> 
> The necessity of bounds-checking is greatly overestimated. There is
> no need to check for the bounds if the language constructs prevent
> indices or iterators going out of the bounds. C lacks such
> constructs, e.g. safe looping over the elements of a container or
> array. In many if not most of the cases this does not involve any
> explicit index at all and if it does, the index is guaranteed within
> the bounds. Such primitives would offer a better performance over
> crude C's pointer arithmetic as well. 

How so? Performance should be the same...
Problem with C arrays is that they are converted to raw pointers
and length information is lost. Errors come out because 
wrong array length is passed around or not at all...

-- 
Click OK to continue...

[toc] | [prev] | [next] | [standalone]

#4718

Melzzzzz wrote:

> > The necessity of bounds-checking is greatly overestimated. There is
> > no need to check for the bounds if the language constructs prevent
> > indices or iterators going out of the bounds. C lacks such
> > constructs, e.g. safe looping over the elements of a container or
> > array. In many if not most of the cases this does not involve any
> > explicit index at all and if it does, the index is guaranteed within
> > the bounds. Such primitives would offer a better performance over
> > crude C's pointer arithmetic as well.
>
> How so? Performance should be the same...

I believe the idea is that the C compiler cannot make assumptions about whether 
pointer operations overlap.  If the compiler knows more then it can optimise 
better.

I'm not sure how much difference this makes in practise (compared, say, to the 
difference between two different compilers, or the output from one compiler 
executed on two different CPUs).

    -- chris 

[toc] | [prev] | [next] | [standalone]

#4721

On Tue, 26 Aug 2014 20:39:41 +0200, Melzzzzz wrote:

> On Tue, 26 Aug 2014 19:35:26 +0200
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>> 
>>> The only ways to get rid of C, in decreasing order of severity are:
>>> 
>>> (a) catastrophic global war, pestilence, or famine;
>>> (b) legislation of an alarmingly authoritarian nature;
>>> (c) the provision of an even more powerful language that is even
>>> more prone to being abused.
>> 
>> (d) liability to the damages caused by software faults.
> 
> Bad programmers write bad programs in any language.

Bad drivers drive any cars poorly. Which does not mean that cars should
have wheels falling out.

Languages should be chosen according to their technical merits and software
quality must be the most important one.

> There is no such language that protects from software faults...

Someone, *not* the customer, must pay for the faults. That would change
everything, languages and programmers included. C is only a symptom. The
real problem is socialization of software development risks and expenses.
Without that languages like C could not survive.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4726

On Tue, 26 Aug 2014 21:38:28 +0200
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> On Tue, 26 Aug 2014 20:39:41 +0200, Melzzzzz wrote:
> 
> > On Tue, 26 Aug 2014 19:35:26 +0200
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> > 
> >> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
> >> 
> >>> The only ways to get rid of C, in decreasing order of severity
> >>> are:
> >>> 
> >>> (a) catastrophic global war, pestilence, or famine;
> >>> (b) legislation of an alarmingly authoritarian nature;
> >>> (c) the provision of an even more powerful language that is even
> >>> more prone to being abused.
> >> 
> >> (d) liability to the damages caused by software faults.
> > 
> > Bad programmers write bad programs in any language.
> 
> Bad drivers drive any cars poorly. Which does not mean that cars
> should have wheels falling out.

C is not car that wheels fall out.

> 
> Languages should be chosen according to their technical merits and
> software quality must be the most important one.

That is why C is chosen when appropriate. Take for example golang.
People now write plan9 assembler instead of C because of
different calling convention (c calls are expensive in go)! When you
want to take out C only that is left is assembler!
Talk me about safety then...

> 
> > There is no such language that protects from software faults...
> 
> Someone, *not* the customer, must pay for the faults. That would
> change everything, languages and programmers included. C is only a
> symptom. The real problem is socialization of software development
> risks and expenses. Without that languages like C could not survive.

There is java... but I heard that there are programmers that make
memory leaks in java. But than again someone has to write those
JNI modules ;)

-- 
Click OK to continue...

[toc] | [prev] | [next] | [standalone]

#4727

On Tue, 26 Aug 2014 23:11:45 +0200, Melzzzzz wrote:

> On Tue, 26 Aug 2014 21:38:28 +0200
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> 
>> On Tue, 26 Aug 2014 20:39:41 +0200, Melzzzzz wrote:
>> 
>>> On Tue, 26 Aug 2014 19:35:26 +0200
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>> 
>>>> On Tue, 26 Aug 2014 18:16:47 +0100, Richard Heathfield wrote:
>>>> 
>>>>> The only ways to get rid of C, in decreasing order of severity
>>>>> are:
>>>>> 
>>>>> (a) catastrophic global war, pestilence, or famine;
>>>>> (b) legislation of an alarmingly authoritarian nature;
>>>>> (c) the provision of an even more powerful language that is even
>>>>> more prone to being abused.
>>>> 
>>>> (d) liability to the damages caused by software faults.
>>> 
>>> Bad programmers write bad programs in any language.
>> 
>> Bad drivers drive any cars poorly. Which does not mean that cars
>> should have wheels falling out.
> 
> C is not car that wheels fall out.

You mean one with wheels nailed to the hull?

>> Languages should be chosen according to their technical merits and
>> software quality must be the most important one.
> 
> That is why C is chosen when appropriate. Take for example golang.
> People now write plan9 assembler instead of C because of
> different calling convention (c calls are expensive in go)! When you
> want to take out C only that is left is assembler!
> Talk me about safety then...

I talk about technical issues. Interoperability, if you want to talk about
it is an issue. And C has huge problems with that as well. Starting with
name mangling schemas nobody knows how working and ending with a nice
ability to call an external function by its name totally ignoring whatever
parameter profile.

That's beside the point, which is again, technical merits.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4730

Dmitry A. Kazakov wrote:


> I talk about technical issues. Interoperability, if you want to talk about
> it is an issue. And C has huge problems with that as well.

I don't think that's true at all.  C is the /only/ language that is callable 
from all the other languages I use.

> Starting with
> name mangling schemas nobody knows how working and ending with a nice
> ability to call an external function by its name totally ignoring whatever
> parameter profile.

Sounds like you're talking about C++, not C.

    -- chris 

[toc] | [prev] | [next] | [standalone]

#4735

On Wed, 27 Aug 2014 10:16:49 +0100, Chris Uppal wrote:

> Dmitry A. Kazakov wrote:
> 
> 
>> I talk about technical issues. Interoperability, if you want to talk about
>> it is an issue. And C has huge problems with that as well.
> 
> I don't think that's true at all.  C is the /only/ language that is callable 
> from all the other languages I use.

Right, but that does not make it good. As in other areas C froze any
possible advance here. We have no better means to bind toughly coupled
software components together than by using unchecked C calls.

>> Starting with
>> name mangling schemas nobody knows how working and ending with a nice
>> ability to call an external function by its name totally ignoring whatever
>> parameter profile.
> 
> Sounds like you're talking about C++, not C.

C++ is a bit better in some aspects (e.g. some rudimentary type checking in
the bindings) and much worse in anything else regarding interoperability.
It is a horror scenario to deal with a library that has C++ interface.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#4737

Chris Uppal wrote:

> Dmitry A. Kazakov wrote:
> 
> 
>> I talk about technical issues. Interoperability, if you want to talk
>> about it is an issue. And C has huge problems with that as well.
> 
> I don't think that's true at all.  C is the /only/ language that is
> callable from all the other languages I use.

In fact, if there is only one binding available for a given library, the 
chances are good that it's a C binding.

> 
>> Starting with
>> name mangling schemas nobody knows how working and ending with a nice
>> ability to call an external function by its name totally ignoring
>> whatever parameter profile.
> 
> Sounds like you're talking about C++, not C.

I spotted that too, and I think it tells us much of what we need to know 
about Mr Kazakov's knowledge of programming languages such as C.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web