Re: [Lit.] Buffer overruns
From: BRG (brg_at_nowhere.org)
Date: 01/06/05
- Next message: BRG: "Re: Help needed for a sorting code in the literature"
- Previous message: Peter Gutmann: "Re: key-exchange in java"
- In reply to: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 06 Jan 2005 11:28:35 +0000
Douglas A. Gwyn wrote:
> BRG wrote:
>
>> The structured programming constructs that we _now_ see in most (all?)
>> modern procedural languages _do_ constrain programmers and seriously
>> restrict their freedom to do whatever they want. Hence to those here
>> who claim that a programming language should not constrain their
>> creativity in any way, their introduction was clearly the work of the
>> devil (as some argued at the time).
>
> If you want to argue against a position, argue against what
> was said, not against some imaginary presentation of the
> position that is of your own devising (aka "straw man").
I don't need to invent a position for you Doug since it is clear from
the arguments that you have repeatedly deployed in defending C that you
consider the relationship between the design of programming languages
and the integrity of software implemented using them to be weak.
In many cases where someone has suggested an area where C is weak your
response has been that it is not useful because it is not needed when
programmers do their job correctly. In other cases your response has
been to simply say it is not in C but is easy to do in C anyway so its
absense from the language is of little, if any, consequence.
But exactly the same is true of assembler so these responses simply
ignore the point being made, which is that these facilities would have a
much stronger impact on the thinking of language users if they were a
full part of the language itself.
And of course the most direct expression of your, at best, weak support
for this principle was in response to a book quote provided by MKS where
you damned it with faint praise by calling it 'vague'.
We hence see that something that Dijkstra considered to be 'profound' is
considered by you to be weak and 'vague'.
> The standard meaning of "structured programming constructs"
> is that the logic is expressed using (a) sequencing, (b)
> conditional iteration, (c) conditional alternation, and
> sometimes (d) recursive subprograms. C certainly provided
> all those from the outset. It also provides other
> facilities that a "structured programming" disciple is not
> supposed to use, and such a person doesn't have to use them.
Yes but that is not the issue I am challenging you on. In your (in my
view entirely unnecessry) defence of C you have been arguing that there
is, at best, a weak relationship between language design and the
integrity of the systems that result. I rather doubt that this is your
true position but it is, nevertheless, the one that you have presented
here as a byproduct of your defence of C.
> C also provided data structuring facilities that contemporary
> languages often were missing, and a more general pointer
> facility that had stronger typing than usual. Along with a
> handful of built-in primitive data types that most systems
> directly support, these were sufficient to construct well
> structured programs to do almost anything worth doing.
>
> The only real difference in this area was that in C pointers
> are more fundamental than arrays, unlike many other PLs.
> That, combined with a standard interface for non-stack based
> dynamic object allocation, has made it extremely easy for C
> programs to effectively use flexible data structures (trees,
> for example), a capability that one would not want to lose.
>
> The *only* significant additional features of the other PLs
> to which you seem to allude are (1) "object" orientation and
> (2) run-time type checking (particularly array limits). The
> former is of value for many (not all) applications, but the
> latter is of very little value for the applications we have
> been discussing, looking at the big picture.
Not in these terms, although these may be your interpretations of my
examples.
My first example is the inadequate support in C for fixed point
arithmetic and sub-range types. This is an integrity feature and also
one that causes significant portability issues for C programs.
My second example is the lack of support for operator overloading for
user defined types. Of course this is somewhat unfair as an observation
on C since few other langauges had got this far when C was introduced.
But the related issue of support for complex numbers was visible at the
time.
However I should stress that I don't see these issues as criticisms of C
as such but rather as reasons not to use C when it is not appropriate.
>> But I live in the real world, one where programmers are not perfect
>> and one in which I have no doubt that the introduction of structured
>> programming constructs into languages has had a strong impact on the
>> integrity of software.
> Perfect programmers are not required. What *is* required
> is the proper kind and degree of discipline in the software
> development process. An examination of reported buffer
> overrun vulnerabilities shows that that is not occurring.
> Further, you *cannot fix* that problem by changing the PL.
> It's at best a partial solution to the entirely wrong problem.
>
>> In the words of Edsger W. Dijkstra: "A Programming Language is a tool
>> that has profound influence on our thinking habits.".
>
> Yeah, for example it can make you lazy and complacent.
So does this mean that (a) you agree with Dijkstra, and (b) you think
that, on balance, programming languages have a detrimental impact on our
thinking habits?
You keep saying that my characterisation of your position is a pure
invention on my part but when faced with a clear exposition of the
principle such as that given by Dijkstra above you dodge the issue of
whether or not you support it by making some offhand disparaging comment
which implies strongly that you don't support it but without actually
saying so.
In overall terms, in the real world and not some idealised version of
it, do you believe that there is any relationship between the design of
a programming language and the integrity of the systems that are
implemented using it? If so, do you consider this relationship to be
significant or of little pratcical consequence?
Brian Gladman
- Next message: BRG: "Re: Help needed for a sorting code in the literature"
- Previous message: Peter Gutmann: "Re: key-exchange in java"
- In reply to: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Next in thread: David Wagner: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
