Re: [Lit.] Buffer overruns

From: Trevor L. Jackson, III (tlj3_at_comcast.net)
Date: 02/01/05 

Date: Mon, 31 Jan 2005 23:36:26 -0500

Fair warning: I disagree with a lot of this, but none of my comments
should be interpreted as criticism, more like a different interpretation
of the same facts. --tj3 (and most of this is OT or only tangential for
sci.crypt)

BRG wrote:

> Douglas A. Gwyn wrote:
>
>> BRG wrote:
>>
>>> ... The downside is that C has unwittingly fostered a culture which
>>> ensures that many of these systems are unreliable and insecure.
>>
>>
>> I dispute that. There are C users who are not part of
>> such a "culture". Therefore other factors are (also?)
>> at work. It would behoove us to identify them.
>
>
> Yes there are many good people working with C. There are many doing
> good work using C. There are superb designs that I have seen in C.
>
> But what I am considering is the average standard of systems engineering
> that we see when we look across the totality of fielded systems written
> in C.

In C or in programming an general? In my experience the vast majority
of software should be rejected unusable and unfixable. I've seen teams
produce utter crap in lots of languages. And the kinds of problems in
the code I've reviewed mostly have nothing to do with the language.
Sure C is easy to misuse, but most procedural languages have weak
points. Those aren't the real problem with most of the software I've
had to review.

My experience includes consulting for medium and large size
organizations to evaluate their software development efforts. Since I
get hired when there are problems I may be committing a sampling error
when I use my experience as a basis. But the literature on software
development methodology is not dissimilar to my experience.

Point is that forcing all of those organizations to another language,
even ADA, would not improve the quality of their output.

>
> There are a huge number of companies putting together and fielding
> abysmally designed systems in C simply because it is so easy and cheap
> to do.

And they would do that in any language. Evan Ada.

> In contrast I have _never_ seen a bucket shop approach used with
> Ada because the culture that comes with Ada _is_ a systems engineering
> culture (I am contrasting Ada and C only because I have a lot of first
> hand experience of managing projects using these two languages).

I think you have committed a sampling error here in that the
self-selected shops that pick Ada as one of the main implementation
languages clearly have an interest in a high quality software rather
than lower cost-to-produce software.

If your force everyone to use Ada you would still see crappy code coming
from people who don't know or care how to do better.

So neither of the above observations about the systems engineering
culture are suitable for generalization.

>
> And of course you are right that there are many cultural influences at
> work. But for whatever reason I believe that their is a link between
> the language and this culture, and that this link has led to the
> fielding of many systems that have been 'put together' rather than
> designed simply because this is so easy to do with C. And my view is
> that this phenomenon partly explains why so many of the software based
> systems we see today lack robustness, reliability and security.

There's a cart/horse issue here. I read the above as suggesting that
because C is so "easy to use" (a description I've never see used before)
it tempts development organizations that would otherwise be diligent and
careful to be indolent and sloppy.

I find that far fetched. I suspect the indolent and sloppy
organizations are the problem and their use of C is irrelevant. For
example, if Modula had become the prevalent language rather than C and
you made the same observations about how really awful the average
practitioner's output was, then you would be blaming Modula, which has a
quite distinct set of strengths and weaknesses from C, for all of the
crappy code that is being written.

Please state why you believe the tools are influencing the people rather
than the people just doing their lazy, half-assed enough-to-get-by jobs.

>
> I don't think it would be credible for anyone within the C community
> with an understanding of systems engineering to claim not to have
> noticed that this was happening.

While I agree this is happening I do not agree that this is new. If has
been happening for over 30 years that I can attest to personally. I'm
sure people with greater experience have seen the same pattern repeated
even longer than that.

So that recent events lead you to believe there is something new under
the sun?

> And yet I don't see much evidence of
> concern about this. The community may not have consciously fostered this
> culture but I don't see that it has done much to counter its deveopment
> either - by and large the community 'has let it happen' as if it is a
> phenomenon that has nothing to do with them.

What duty do you believe the community has to counter the tendency you
describe? If, in fact, the problem is not the language but the people
and the organizations, then what duty does the community (or its
leaders) have to change people?

>
> All of this is what I mean when I say that a programming language has a
> powerful influence on the way people approach the process of producing
> solutions - if we put so much emphasis during people's education and
> training on low level design, we should not then be surprised when this
> is the level at which they design things.

That's an educational issue rather than an language issue. At what
point can a student or trainee even conceive of the issues in a
high-level design? I suspect the problem is lack of sufficient
education and experience rather than the wrong kind.

>
>>> I totally agree with you that this is primarily an educational issue.
>>> But its not new and yet we don't seem to have been able to do
>>> anything about it.
>>

It's a motivation issue. Most educational issues are. if the student
is not interested in learning there is nothing that _anyone_ can do to
make them. But a student interested in learning will do whatever it
takes to gain what they want.

>>
>> Certainly not if the problem is insufficiently widely
>> appreciated, and we all give up in advance rather than
>> trying to address it.
>
>
> Agreed. But I get despondent when the systems engineering impact of the
> link between a programming language and the culture that builds up
> around it is denied by senior people in the C community such as
> yourself.

Why is it that you believe those cultural defects derive from the
language rather than from the conditions under which the people are
working? If the development organizations wanted robustness,
reliability, and security they would demand them. And they would
probably get them. But they don't demand them, so of course they don't
get them.

> And, I admit, also a little despondent when we spend so much
> time on a small issue like ABC when there are big issues at stake such
> as "why is systems engineering going wrong in so much of the C community"

It isn't going wrong in only the C community. It is going wrong in the
entire software development industry. See Yourdon's "Decline and Fall
of the American Programmer" or Glass's "Facts and Fallacies of Software
Engineering".

Is there something you believe the C community could do that the larger
community could not? I.e., what makes the decline of quality in C code
especially lamentable?

>
> I have a lot more I could say (on solutions) but its 2:00 in the morning
> here so I am going to bed! Please don't think I am getting at you
> personally in any of this.

If we are focused on the issue rather than the people expressing them
we'll probably be able to maintain a higher quality of discussion. That
said, feel free to express how you _really_ feel. ;-)

/tj3

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... this is a long rant about the links between language ... Both to some extent but definitely worse within the C community than in, ... >> culture (I am contrasting Ada and C only because I have a lot of first ... culture of low level design that it has unwittingly fostered. ...
    (sci.crypt)
  • Re: Time Out for Time City Biel(D)-Bienne(F)
    ... community. ... language thru religious zeal (and unlike some other zealots, the Amish are ... most of that culture has been lost. ... for the survival or our multi cultural / language State is also IMHO ...
    (alt.horology)
  • Re: [Lit.] Buffer overruns
    ... But what I am considering is the average standard of systems engineering ... Ada because the culture that comes with Ada _is_ a systems engineering ... I don't think it would be credible for anyone within the C community ... is the level at which they design things. ...
    (sci.crypt)
  • Re: [Lit.] Buffer overruns
    ... >>community might diverge from that of the C community much quicker than I ... causal relationship between the language and the observed reliability - ... In my view its the culture and not the language that is the driver. ... I also notice that earthlings seem to have 'magic dust' of various sorts ...
    (sci.crypt)
  • Re: What does it mean
    ... maintainance nightmare IMHO is language, culture and religion. ... can still be more expensive to get more workers at regular pay... ... However, those aren't the only ghettos that exist, ...
    (rec.games.computer.ultima.dragons)